96
Mikrotik - mehrere VLANs auf cAP AC mit CAPsMAN
Hallo,
ich bin in diesem Forum auf einen Betrag gestoßen, der mein Problem aber nur teilweise löst.
Mikrotik - VLAN - WLAN - DGS1210-24 - cAP AC])
Ich würde mich freuen, wenn mich jemand dabei unterstützen könnte, eine lauffähige Konfiguration zu erstellen:
Ich habe die Anleitung verfolgt und auf meinem RB3011 die VLANs mit VLAN-Filtering laufen. Über einen SFP-Trunk werden alle VLANs einen Cisco Switch übertragen, der diese dann über seine Ports "untagged" zur Verfügung stellt.
Mein Vorhaben:
Ich möchte den cAP über CAPsMAN managen. Mein Management VLAN ist VLAN1(admin)
Über die Funkschnittstelle des cAPs sollen nun VLAN60 und VLAN70 bereitgestellt werden. Aktuell ist der cAP mit dem CAPsMan verbunden und VLAN1 wird per Funk bereitgestellt. Grundsätzlich läuft der cAP AC daher schon. Leider fehlt mir der Ansatz, wie ich den cAP selber konfigurieren muss um dann über den CAPsMAN die beiden VLANS bereitstellen zu können. Ich nehme mal an, dass ich am Cisco Switch einen Uplink Port für den cAP konfigurieren muss der dann VLAN1 (untagged), VLAN60( tagged) und VLAN70 (tagged) bereitstellt. Und weiter komme ich jetzt nicht!
Danke und Gruß,
Spartacus.
ich bin in diesem Forum auf einen Betrag gestoßen, der mein Problem aber nur teilweise löst.
Mikrotik - VLAN - WLAN - DGS1210-24 - cAP AC])
Ich würde mich freuen, wenn mich jemand dabei unterstützen könnte, eine lauffähige Konfiguration zu erstellen:
Ich habe die Anleitung verfolgt und auf meinem RB3011 die VLANs mit VLAN-Filtering laufen. Über einen SFP-Trunk werden alle VLANs einen Cisco Switch übertragen, der diese dann über seine Ports "untagged" zur Verfügung stellt.
Mein Vorhaben:
Ich möchte den cAP über CAPsMAN managen. Mein Management VLAN ist VLAN1(admin)
Über die Funkschnittstelle des cAPs sollen nun VLAN60 und VLAN70 bereitgestellt werden. Aktuell ist der cAP mit dem CAPsMan verbunden und VLAN1 wird per Funk bereitgestellt. Grundsätzlich läuft der cAP AC daher schon. Leider fehlt mir der Ansatz, wie ich den cAP selber konfigurieren muss um dann über den CAPsMAN die beiden VLANS bereitstellen zu können. Ich nehme mal an, dass ich am Cisco Switch einen Uplink Port für den cAP konfigurieren muss der dann VLAN1 (untagged), VLAN60( tagged) und VLAN70 (tagged) bereitstellt. Und weiter komme ich jetzt nicht!
Danke und Gruß,
Spartacus.
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: 378188
Url: https://administrator.de/contentid/378188
Printed on: April 26, 2024 at 15:04 o'clock
96 Comments
Latest comment
Das Tutorial hier sollte dir helfen und alle Fragen beantworten:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Ist der Cisco ein Catalyst Switch oder einer aus der biligen SoHo Serie SFx00 oder SGx00 ?
Für beide Modelle findest du hier ein Beispiel wie man die Trunk bzw. Tagged Ports richtig konfiguriert:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Damit sollte dein Setup dann im Handumdrehen erledigt sein !
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Ich nehme mal an, dass ich am Cisco Switch einen Uplink Port für den cAP konfigurieren muss der dann VLAN1 (untagged), VLAN60( tagged) und VLAN70 (tagged) bereitstellt.
Genau so ist es !Ist der Cisco ein Catalyst Switch oder einer aus der biligen SoHo Serie SFx00 oder SGx00 ?
Für beide Modelle findest du hier ein Beispiel wie man die Trunk bzw. Tagged Ports richtig konfiguriert:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Damit sollte dein Setup dann im Handumdrehen erledigt sein !
Hi aqui,
danke für die Antwort. Das VLAN Setup zwischen Cisco SG2500 und Mikrotik RB3011 läuft einwandfrei.
Was mir fehlt, ist , wie ich den cAP über den CAPsMAN richtig konfigurieren muss.
Konkret:
im CAPsMAN auf dem RB3011 habe ich zwei neue Interfaces
Dem cap2 ist eine Konfiguration mit SSID zugeordnet; der cAP zieht sich eine IP aus dem vlan1-Subnetz und dieses wird über den cAP in den Äther geblasen.
Aber genau dieses Subnetz ist das "admin-vlan" und soll nur für den cAP selber sein. Irgendwie muss ich dem cAP beibringen, dass er vlan60 und vlan70 funkt und ich über vlan1 nur das Webinterface vom cAP erreichen kann.
Wie ich den Trunk am Cisco einstelle, ist mir klar. Das funktioniert auch schon, aber ich habe die Schwierigkeiten vlan60 und vlan70 über CAPsMAN zuzuordnen. Außerdem ist mit unklar, wie ich das vlan1 auf dem cAP isolieren kann. Geht das auch über CAPsMAN, oder muss ich am cAP selber Hand anlegen.
Danke und Gruß,
Spartacus
danke für die Antwort. Das VLAN Setup zwischen Cisco SG2500 und Mikrotik RB3011 läuft einwandfrei.
Was mir fehlt, ist , wie ich den cAP über den CAPsMAN richtig konfigurieren muss.
Konkret:
im CAPsMAN auf dem RB3011 habe ich zwei neue Interfaces
- 2,4 GHz-WLAN (cap2)
- 5GHz WLAN (cap1)
Dem cap2 ist eine Konfiguration mit SSID zugeordnet; der cAP zieht sich eine IP aus dem vlan1-Subnetz und dieses wird über den cAP in den Äther geblasen.
Aber genau dieses Subnetz ist das "admin-vlan" und soll nur für den cAP selber sein. Irgendwie muss ich dem cAP beibringen, dass er vlan60 und vlan70 funkt und ich über vlan1 nur das Webinterface vom cAP erreichen kann.
Wie ich den Trunk am Cisco einstelle, ist mir klar. Das funktioniert auch schon, aber ich habe die Schwierigkeiten vlan60 und vlan70 über CAPsMAN zuzuordnen. Außerdem ist mit unklar, wie ich das vlan1 auf dem cAP isolieren kann. Geht das auch über CAPsMAN, oder muss ich am cAP selber Hand anlegen.
Danke und Gruß,
Spartacus
Du darfst an das vlan1 des APs keine SSID binden ! Dieses muss vollkommen isoliert sein vom Traffic der VLANs die an die entsprechenden SSIDs gebunden werden.
Das VLAN1 darf nirgendwo in Funk VLANs gelangen. Das musst du sicherstellen. Also via der Bridge nur die VLANs koppeln im CAPsMAN die da ran sollen.
Hier solltest du IMMER Local Forwarding machen rein schon aus Performance Gründen. Niemals den Traffic auf den CAPsMAN tunnel, das skaliert nicht ! Ausnahme z.B. Gast WLAN was man ja zentral über die Firewall kontrollieren will.
Das o.a. VLAN Tutorial zeigt wie das geht aber eben nur auf statischem Wege, ohne CAPsMAN.
Für die CAPsMAN Einrichtung hilft ggf.:
https://www.youtube.com/watch?v=RJGp03g1xS8
und auch
https://www.youtube.com/watch?v=HxWE4NfrSv8
Ggf. checke ich das nochmal im Labor damit.
Das VLAN1 darf nirgendwo in Funk VLANs gelangen. Das musst du sicherstellen. Also via der Bridge nur die VLANs koppeln im CAPsMAN die da ran sollen.
Hier solltest du IMMER Local Forwarding machen rein schon aus Performance Gründen. Niemals den Traffic auf den CAPsMAN tunnel, das skaliert nicht ! Ausnahme z.B. Gast WLAN was man ja zentral über die Firewall kontrollieren will.
Das o.a. VLAN Tutorial zeigt wie das geht aber eben nur auf statischem Wege, ohne CAPsMAN.
Für die CAPsMAN Einrichtung hilft ggf.:
https://www.youtube.com/watch?v=RJGp03g1xS8
und auch
https://www.youtube.com/watch?v=HxWE4NfrSv8
Ggf. checke ich das nochmal im Labor damit.
Hi aqui,
danke nochmals für Deinen Support. Ich werde morgen mal versuchen, das zu konfigurieren.
Noch einmal zum Vesrtändnis.
Das sollte dann eigentlich alles sein, oder?
Danke nochmals,
Gruß,
Christian
danke nochmals für Deinen Support. Ich werde morgen mal versuchen, das zu konfigurieren.
Noch einmal zum Vesrtändnis.
- ich lege alle VLANs als Trunk auf ether1 des cAPs
- ich konfiguriere unter CAPsMAN->Configurations für jedes VLAN eine eigene SSID (ohne VLAN1)
- im Datapath des CAPsMAN wähle ich unter "bridge" meine RB3011-Bridge aus, an der die VLANs (Bridge mit VLAN filtering) gebunden sind
- unter "VLAN Mode" stelle ich "no tag" ein
- VLAN-ID ist dann eines meiner "getrukten" VLANs, welches gefunkt werden soll.
Das sollte dann eigentlich alles sein, oder?
Danke nochmals,
Gruß,
Christian
ich lege alle VLANs als Trunk auf ether1 des cAPs
Ja, wenn ein Trunk für dich ein tagged Uplink ist (In nicht Cisco Netzwerk Sprech ist das eine Link Aggregation)Nur die VLANs die auf eine SSID gemappt sind reicht.
ich konfiguriere unter CAPsMAN->Configurations für jedes VLAN eine eigene SSID
Ja, wenn du mit MSSID arbeiten willst oder musst. Das geht nur mit Virtuellen APs die du vorher einrichten musst !Denk dran das du das 2,4Ghz und 5 Ghz WLAN dann auch mit dem VLAN in einer Bridge zusammenfasst wenn du beide Bänder abdecken willst bzw. dein cAP dual Radio kann. Möglich auch das man jedes Band in eine separate SSID legt aber das ist eher unüblich. Du willst ja sicher beide Bänder bedienen pro VLAN.
im Datapath des CAPsMAN wähle ich unter "bridge" meine RB3011-Bridge aus
Das besser nicht, denn dann tunnelst du allen Traffic des gesamten VLANs zentral auf den 3011er.Das ist wenig performant, denn der gesamte WLAN Traffic quält sich so über einen Tunnel zum 3011 um dann dort in die Netzwerk Infrastruktur zu gehen.
Du kannst das machen auch für einzelne SSIDs wie Gastnetz usw. wenn du einen zentralen Punkt zur Sicherung des gesamten Traffics haben willst (Firewall).
Sinnvoller und weitaus performanter ist aber immer mit Local Forwarding zu arbeiten, so das der Traffic gleich beim AP selber auf das Netzwerk ausgekoppelt wird. Dann nutzt man halt die Bridge auf dem AP.
Daszu musst du dann "Local Forwarding" anhaken.
VLAN-ID ist dann eines meiner "getrukten" VLANs, welches gefunkt werden soll.
Richtig !
Hi aqui,
hm! Danke für deine Antwort. Bin mir nicht sicher, ob ich es gepeilt habe. Ich fange einfach mal an!
Ich muss dann für Local Forwarding aber auch erst die Bridge auf dem cAP konfigurieren. Ich schau mal, ob ich die einstellungen im CAPsMAN alle finde...
Danke Dir,
Christian
hm! Danke für deine Antwort. Bin mir nicht sicher, ob ich es gepeilt habe. Ich fange einfach mal an!
Ich muss dann für Local Forwarding aber auch erst die Bridge auf dem cAP konfigurieren. Ich schau mal, ob ich die einstellungen im CAPsMAN alle finde...
Danke Dir,
Christian
Ja !
Die Bridge brauchst du immer dann wenn dein WLAN auch im gleichen IP Segment liegen soll wie dein VLAN.
Der MT ist ja primär Router und sieht das WLAN erstmal als normalen gerouteten Interface Port.
Behandelst du das so liegen die WLANs dann logischerweise immer in einem eigenen IP Segment und der MT routet diese.
Das will man ja häufig nicht sondern das WLAN soll im gleichen Layer 2 Netz liegen was am LAN Port des APs auch angeschlossen ist.
Dann muss man natürlich das LAN Interface und das WLAN Interface in eine Bridge packen damit die aus Layer 2 Sicht wieder in einem gemeinsamen Netz liegen... logisch.
Bei VLANs und MSSID bridgest du dann halt das VLAN mit dem WLAN.
Zieh dir in Ruhe nochmal die Videos der "Pascom Brüder" von YouTube rein. Die erklären das dort eigentlich ganz gut.
Die Bridge brauchst du immer dann wenn dein WLAN auch im gleichen IP Segment liegen soll wie dein VLAN.
Der MT ist ja primär Router und sieht das WLAN erstmal als normalen gerouteten Interface Port.
Behandelst du das so liegen die WLANs dann logischerweise immer in einem eigenen IP Segment und der MT routet diese.
Das will man ja häufig nicht sondern das WLAN soll im gleichen Layer 2 Netz liegen was am LAN Port des APs auch angeschlossen ist.
Dann muss man natürlich das LAN Interface und das WLAN Interface in eine Bridge packen damit die aus Layer 2 Sicht wieder in einem gemeinsamen Netz liegen... logisch.
Bei VLANs und MSSID bridgest du dann halt das VLAN mit dem WLAN.
Ich schau mal, ob ich die einstellungen im CAPsMAN alle finde...
Ja, sind dort alle auch. Man holt ja einfach nur die cAP Konfig auf den CAPsMAN rüber.Zieh dir in Ruhe nochmal die Videos der "Pascom Brüder" von YouTube rein. Die erklären das dort eigentlich ganz gut.
Hallo aqi,
ich danke Dir erst einmal für Deine Geduld, aber ich kriegt das nicht auf die Kette
Ich kriege nur VLAN1 gefunkt. Die Pascom Brüder haben mir da auch nicht viel weiter geholfen,da sie auf das Thema VLAN und CAPsMAN nicht eingehen, oder habe ich etwas übersehen?
Sorry, aber irgendwie bin ich immer noch "lost"
Vielleicht noch mal ein Nachtrag um mein Verständnis zu festigen:
Auf dem RB3011 have ich ein bridge "br_vlan" an die alle VLANS gekoppelt sind. Konfiguriere ich jetzt unter "br_vlan->VLANs" cap1/cap2 als untagged zu?!?
Gruß,
Christian
ich danke Dir erst einmal für Deine Geduld, aber ich kriegt das nicht auf die Kette
- Mir ist unklar, wir die lokale cAPs-Konfig aussehen muss, um das Admin-LAN (VLAN1) nur für den cAP selbst freizugeben. Muss ich hier jetzt meine VLANS analog zum RB3011 anlegen?
- Mir ist ebenfalls unklar, ob ich auf dem cAP lokale Firewall-Regeln benötige, wenn ich "local-forwaring" benutze. Es ist so, dass ich auf dem RB die VLANs grundsätzlich voneinander abschotte und nur bestimmen VLANs erlaube miteinander zu kommunizieren. Das regele ich auf dem RB über Address-Lists und so wie ich es momentan verstehe, muss ich bei "local-Forwarding" das analog auf allen cAPs einbauen.
- Mir ist auch noch nicht klar, wie ich im CAPsMAN die VLAN-Einstellungen für VLAN60 und VLAN99 mache. Habe gestern mal versucht, dies unter Datapath einzurichten, hat aber nicht geklappt.
Ich kriege nur VLAN1 gefunkt. Die Pascom Brüder haben mir da auch nicht viel weiter geholfen,da sie auf das Thema VLAN und CAPsMAN nicht eingehen, oder habe ich etwas übersehen?
Sorry, aber irgendwie bin ich immer noch "lost"
Vielleicht noch mal ein Nachtrag um mein Verständnis zu festigen:
Auf dem RB3011 have ich ein bridge "br_vlan" an die alle VLANS gekoppelt sind. Konfiguriere ich jetzt unter "br_vlan->VLANs" cap1/cap2 als untagged zu?!?
Gruß,
Christian
Sieh dir das mal genau im MT VLAN Tutorial an:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Dort ist es beschrieben wie es ohne CAPsMAN geht. Vielleicht "übst" du das erstmal ohne CAPsMAN, das ist im ersten Schritt einfacher.
Für MSSID Funktion also mehrere WLANs aufspannen pro AP musst du virtuelle APs anlegen (siehe Tutorial !) sonst geht das nicht. Also virtuelle APs und die dann an deine VLANs 60 und 99 flanschen.
Mach das besser erstmal "zu Fuß" ohne CAPsMAN um zu sehen wie es grundsätzlich geht.
Genau so musst du das später auch mit CAPsMAN. Es ist ja identisch, da ja die Interface nur virtuell auf den Controller gezogen werden.
Idealerweise macht man das dann mit einem Template...wenns denn rennt.
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Dort ist es beschrieben wie es ohne CAPsMAN geht. Vielleicht "übst" du das erstmal ohne CAPsMAN, das ist im ersten Schritt einfacher.
Für MSSID Funktion also mehrere WLANs aufspannen pro AP musst du virtuelle APs anlegen (siehe Tutorial !) sonst geht das nicht. Also virtuelle APs und die dann an deine VLANs 60 und 99 flanschen.
Mach das besser erstmal "zu Fuß" ohne CAPsMAN um zu sehen wie es grundsätzlich geht.
Genau so musst du das später auch mit CAPsMAN. Es ist ja identisch, da ja die Interface nur virtuell auf den Controller gezogen werden.
Idealerweise macht man das dann mit einem Template...wenns denn rennt.
Hallo aqui,
so, ich bin etwas weiter, aber es funktioniert noch nicht richtig, daher habe ich mal meine Konfiguartion angefügt:
Ich kann jetzt beide Netzte (Intranet und Gast sehen) Mit Intranet kann ich mich auch verbinden und ich bekomme auch eine IP aus dem VLAN60 zugeordnet. VLAN70 erscheint zwar, aber es kann keine IP bezogen werden. Über einen "untagged" Port am Cisco bekomme ich VLAN70 korrekt zugewiesen und auch im Trunk zum cAP ist VLAN 70 konfiguriert. "br_vlan" ist hier die lokale bridge auf dem RB3011 anauf der alle VLANS per Filtering konfiguriert sind.
Wie gesagt, über entsprechende "untagged-Ports" an meinen Switchen, sind alle Subnetze einwandfrei erreichbar. Irgendwo liegt in der "Slave"-Config im CAPsMAN/cAP noch der Hund begraben, kannst du etwas erkennen?
Ganz lieben Dank und Gruß,
Spartacus
so, ich bin etwas weiter, aber es funktioniert noch nicht richtig, daher habe ich mal meine Konfiguartion angefügt:
Ich kann jetzt beide Netzte (Intranet und Gast sehen) Mit Intranet kann ich mich auch verbinden und ich bekomme auch eine IP aus dem VLAN60 zugeordnet. VLAN70 erscheint zwar, aber es kann keine IP bezogen werden. Über einen "untagged" Port am Cisco bekomme ich VLAN70 korrekt zugewiesen und auch im Trunk zum cAP ist VLAN 70 konfiguriert. "br_vlan" ist hier die lokale bridge auf dem RB3011 anauf der alle VLANS per Filtering konfiguriert sind.
Wie gesagt, über entsprechende "untagged-Ports" an meinen Switchen, sind alle Subnetze einwandfrei erreichbar. Irgendwo liegt in der "Slave"-Config im CAPsMAN/cAP noch der Hund begraben, kannst du etwas erkennen?
Ganz lieben Dank und Gruß,
Spartacus
########################################################################################
##
## cAP-Config
##
########################################################################################
/interface bridge add admin-mac=XX:XX:XX:XX:XX:XX auto-mac=no comment=defconf name=bridge
/interface wireless
# managed by CAPsMAN
# channel: 2412/20-Ce/gn(20dBm), SSID: Intranet, local forwarding
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-Ce \
disabled=no distance=indoors frequency=auto mode=ap-bridge ssid=\
MikroTik-F61D7F wireless-protocol=802.11
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=\
20/40/80mhz-Ceee disabled=no distance=indoors frequency=auto mode=\
ap-bridge ssid=MikroTik-F61D80 wireless-protocol=802.11
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface wireless
# managed by CAPsMAN
# SSID: Gast, local forwarding
add area="" arp=enabled bridge-mode=enabled default-ap-tx-limit=0 \
default-authentication=yes default-client-tx-limit=0 default-forwarding=\
yes disable-running-check=no disabled=no hide-ssid=no \
interworking-profile=disabled keepalive-frames=enabled l2mtu=1600 \
mac-address=XX:XX:XX:XX:XX:XX master-interface=wlan1 max-station-count=\
2007 mode=station mtu=1500 multicast-buffering=enabled multicast-helper=\
default name=wlan3 security-profile=default ssid=MikroTik \
station-bridge-clone-mac=00:00:00:00:00:00 station-roaming=enabled \
update-stats-interval=disabled vlan-id=1 vlan-mode=no-tag wds-cost-range=\
50-150 wds-default-bridge=none wds-default-cost=100 wds-ignore-ssid=no \
wds-mode=disabled wmm-support=disabled wps-mode=push-button
/interface bridge port
add bridge=bridge comment=defconf interface=ether1
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=wlan1
add bridge=bridge comment=defconf interface=wlan2
/interface wireless cap
#
set certificate=request discovery-interfaces=ether1 enabled=yes interfaces=\
wlan1 lock-to-caps-man=yes static-virtual=yes
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface= bridge
########################################################################################
##
## RB3011-Config
##
########################################################################################
/caps-man channel
add band=2ghz-b/g/n control-channel-width=20mhz frequency=2412 name=channel01
add band=2ghz-b/g/n control-channel-width=20mhz frequency=2417 name=channel02
add band=2ghz-b/g/n control-channel-width=20mhz frequency=2422 name=channel03
add band=2ghz-b/g/n control-channel-width=20mhz frequency=2427 name=channel04
add band=2ghz-b/g/n control-channel-width=20mhz frequency=2432 name=channel05
add band=2ghz-b/g/n control-channel-width=20mhz frequency=2437 name=channel06
add band=2ghz-b/g/n control-channel-width=20mhz frequency=2442 name=channel07
add band=2ghz-b/g/n control-channel-width=20mhz frequency=2447 name=channel08
add band=2ghz-b/g/n control-channel-width=20mhz frequency=2452 name=channel09
add band=2ghz-b/g/n control-channel-width=20mhz frequency=2457 name=channel10
add band=2ghz-b/g/n control-channel-width=20mhz frequency=2462 name=channel11
add band=2ghz-b/g/n control-channel-width=20mhz frequency=2467 name=channel12
add band=2ghz-b/g/n control-channel-width=20mhz frequency=2472 name=channel13
add band=2ghz-b/g/n control-channel-width=20mhz frequency=2484 name=channel14
/caps-man datapath
add local-forwarding=yes name=vlan60 vlan-id=60 vlan-mode=use-tag
add local-forwarding=yes name=vlan70 vlan-id=70 vlan-mode=use-tag
#
/caps-man security
add authentication-types=wpa2-psk encryption=aes-ccm name=Intranet \
passphrase=1234567890
add authentication-types=wpa2-psk encryption=aes-ccm name=Guests passphrase=\
1234567890
#
/caps-man configuration
add channel=channel01 country=germany datapath=vlan60 datapath.bridge=br_vlan \
datapath.local-forwarding=yes datapath.vlan-id=60 datapath.vlan-mode=\
use-tag mode=ap name=intranet security=Intranet ssid=Intranet
add channel=channel11 country=germany datapath=vlan70 datapath.bridge=br_vlan \
datapath.local-forwarding=yes datapath.vlan-id=70 datapath.vlan-mode=\
use-tag mode=ap name=guests security=Guests ssid=Gast
#
/caps-man manager set ca-certificate=auto certificate=auto enabled=yes
/caps-man manager interface add disabled=no interface=vlan1
/caps-man provisioning add action=create-dynamic-enabled master-configuration=intranet name-prefix=\
vlan radio-mac=xx:xx:xx:xx:xx:xx slave-configurations=guestsVLAN70 erscheint zwar, aber es kann keine IP bezogen werden
Da stimmt dann irgendwas mit der Bridge noch nicht die das VLAN 70 verbindet.Checke da nochmal genau ob du überall das Tagging oder eben nicht Tagging richtig eingestellt hast insbesondere bei den virtuellen Ports die auf die Bridge connecten.
Es gibt keine Layer 2 Connectivity in dem VLAN 70 zwischen Funk und dem Draht. Das ist das typische Verhalten wenn die DHCP Broadcasts nicht durchkommen. Deshalb solltest du auch bei einer statischen IP vermutlich keine Verbindung auf Kabel Endgeräte im VLAN 70 haben. Ping müsste auch mit statischer IP fehlschlagen.
Mit "Cisco" meinst du da einen Catalysten oder einen SG SoHo Switch ?
Der cAP muss da tagged angeschlossen sein im VLAN 60 und 70 aber hast du vermutlich, oder ?
Hi aqui,
ich habe das noch mal gecheckt. Der cAP ist über den Cisco SG200 angebunden. Es liegen alle vlans als "tagged" an, außer VLAN1.
Ping auf das GW hatte ich getestet, bevor ich die Firewall-Rules aufgestellt hatte. Das klappte einwandfrei in jedem VLAN. Inzwischen habe ich das aber per FW unterbunden. Ping auf andere Netzkomponenten im gleichen vlan klappt einwandfrei und die Kommunikation läuft eigentlich auch schon seit ein paar Wochen störungsfrei im "Kabelnetz" über einen SG200 und einen SG250, die per SFT-Trunk an den Mikrotik gekoppelt sind (Mikrotik-SFP-> SFP1-SG200-SFP2->SFP1-SG250). Die anderen vlans (z.B. vlan99) laufen auch nicht am cAP und da hängen via Kabel bestimmt 20 Clients drin.
Ich habe hier noch einmal meine vlan-Konfig auf "br_vlan" gepostet. Vielleicht findest Du ja etwas:
Ach ja, Du sagtest die virtuellen caps müssen als Ports auch hinzugefügt werden, oder habe ich das falsch verstanden? Wo genau muss ich die einbauen, bei "interface bridge vlan ", als "tagged"?
ich habe das noch mal gecheckt. Der cAP ist über den Cisco SG200 angebunden. Es liegen alle vlans als "tagged" an, außer VLAN1.
Ping auf das GW hatte ich getestet, bevor ich die Firewall-Rules aufgestellt hatte. Das klappte einwandfrei in jedem VLAN. Inzwischen habe ich das aber per FW unterbunden. Ping auf andere Netzkomponenten im gleichen vlan klappt einwandfrei und die Kommunikation läuft eigentlich auch schon seit ein paar Wochen störungsfrei im "Kabelnetz" über einen SG200 und einen SG250, die per SFT-Trunk an den Mikrotik gekoppelt sind (Mikrotik-SFP-> SFP1-SG200-SFP2->SFP1-SG250). Die anderen vlans (z.B. vlan99) laufen auch nicht am cAP und da hängen via Kabel bestimmt 20 Clients drin.
Ich habe hier noch einmal meine vlan-Konfig auf "br_vlan" gepostet. Vielleicht findest Du ja etwas:
Ach ja, Du sagtest die virtuellen caps müssen als Ports auch hinzugefügt werden, oder habe ich das falsch verstanden? Wo genau muss ich die einbauen, bei "interface bridge vlan ", als "tagged"?
/interface bridge
add fast-forward=no name=br_vlan vlan-filtering=yes
#
/interface vlan
add comment=Admin interface=br_vlan name=vlan1 vlan-id=1
add comment=Office interface=br_vlan name=vlan10 vlan-id=10
add comment=VoiP interface=br_vlan name=vlan20 vlan-id=20
add comment=Sonos interface=br_vlan name=vlan30 vlan-id=30
add comment=IPTV interface=br_vlan name=vlan40 vlan-id=40
add comment=SmartHome interface=br_vlan name=vlan50 vlan-id=50
add comment=WLAN interface=br_vlan name=vlan60 vlan-id=60
add comment=Gast interface=br_vlan name=vlan70 vlan-id=70
add comment=Gaming interface=br_vlan name=vlan80 vlan-id=80
add comment=FritzBox interface=br_vlan name=vlan99 vlan-id=99
#
/interface list
add name=WAN
add name=LAN
add name=MAC-WinBox
#
/interface bridge port
add bridge=br_vlan hw=no interface=sfp1
add bridge=br_vlan frame-types=admit-only-untagged-and-priority-tagged \
interface=ether2
add bridge=br_vlan frame-types=admit-only-untagged-and-priority-tagged \
interface=ether3 pvid=10
add bridge=br_vlan frame-types=admit-only-untagged-and-priority-tagged \
interface=ether4 pvid=20
add bridge=br_vlan frame-types=admit-only-untagged-and-priority-tagged \
interface=ether10 pvid=99
add bridge=br_vlan frame-types=admit-only-untagged-and-priority-tagged \
interface=ether5 pvid=50
add bridge=br_vlan interface=ether6
#
/interface bridge vlan
add bridge=br_vlan comment=Admin tagged=br_vlan,vlan1 untagged=sfp1,ether6 \
vlan-ids=1
add bridge=br_vlan comment=Office tagged=sfp1,br_vlan,vlan10 untagged=ether3 \
vlan-ids=10
add bridge=br_vlan comment=VoIP tagged=sfp1,br_vlan,vlan20 untagged=ether4 \
vlan-ids=20
add bridge=br_vlan comment=FritzBox tagged=sfp1,br_vlan,vlan99 untagged=\
ether10,*1A vlan-ids=99
add bridge=br_vlan comment=SmartHome tagged=sfp1,br_vlan,vlan50 untagged=\
ether5 vlan-ids=50
add bridge=br_vlan comment=Sonos tagged=sfp1,br_vlan,vlan30 vlan-ids=30
add bridge=br_vlan comment=IPTV tagged=sfp1,br_vlan,vlan40 vlan-ids=40
add bridge=br_vlan comment=WLAN tagged=sfp1,br_vlan,vlan60,vlan99 vlan-ids=60
add bridge=br_vlan comment=Gast tagged=sfp1,br_vlan,vlan70 vlan-ids=70
add bridge=br_vlan comment=Gaming tagged=sfp1,br_vlan,vlan80 vlan-ids=80
#Der cAP ist über den Cisco SG200 angebunden. Es liegen alle vlans als "tagged" an, außer VLAN1.
Das ist auch richtig so !Ping auf das GW hatte ich getestet, bevor ich die Firewall-Rules aufgestellt hatte. Das klappte einwandfrei in jedem VLAN.
Auch via WLAN ? Oder meinst du hier ausschliesslich die Kabel gebundenen VLANs ? Vermutlich ja, oder ?Ich ahne aber schon wo ggf. der Fehler ist wenn du einen 2011er oder 3011er MT betreibst.
Die Portgruppen SFP1, eth 1 bis 5 und eth 5-10 liegen auf unterschiedlichen Chipsätzen die NICHT miteinander gekoppelt sind !
Du kannst also Port 10 nicht an eine Bridge klemmen die Ports 1 bis 5 bedient. Das geht nicht. Deshalb ist in der Default die beiden Port Gruppen mit einer Bridge gekoppelt.
Löschst du die Default Konfig was man ja in so einem Individual Design immer macht sind auch die Portgruppen wieder getrennt !
Da musst du aufpassen ! Guckst du auch hier:
https://i.mt.lv/routerboard/files/Block-RB2011.pdf
Die 100Mbit Portgruppen sind also von den 1Gig Portgruppen physisch getrennt !
Hast du das in deinem o.a. Bridge Design bedacht ?!
Hi aqui,
das mit dem ping habe ich ausschließlich im kabelgebunden VLANs getestet. WLAN klappt ja noch nicht
Das mit den Ports auf dem 3011er verstehe ich jetzt nicht.
Die VLANs kommen doch alle über SFP auf dem Cisco an? Und der cAP hängt auch an einem diese Cisco-Ports.
Wenn ich an diesen Trunk-Port einen kabelgebundenen Client hänge, klappt es mit dem VLAN
Der cAP holt sich ja auch das Master-VLAN (hier vlan60) Nur die als Client konfigurierten vlans (70,99) werden nicht durchgelassen.
Wieso soll das an den Chipsätzen auf dem RB3011 liegen? Wo ist der Unterschied, zwischen dem cAP und dem "Kabel"-Client an dem Cisco Switch? Das verstehe ich jetzt nicht!
Christian
das mit dem ping habe ich ausschließlich im kabelgebunden VLANs getestet. WLAN klappt ja noch nicht
Das mit den Ports auf dem 3011er verstehe ich jetzt nicht.
Die VLANs kommen doch alle über SFP auf dem Cisco an? Und der cAP hängt auch an einem diese Cisco-Ports.
Wenn ich an diesen Trunk-Port einen kabelgebundenen Client hänge, klappt es mit dem VLAN
Der cAP holt sich ja auch das Master-VLAN (hier vlan60) Nur die als Client konfigurierten vlans (70,99) werden nicht durchgelassen.
Wieso soll das an den Chipsätzen auf dem RB3011 liegen? Wo ist der Unterschied, zwischen dem cAP und dem "Kabel"-Client an dem Cisco Switch? Das verstehe ich jetzt nicht!
Christian
Oben hast du aber die physischen Interfaces 6 und 10 der Bridge hinzugefügt und das klappt jedenfalls beim 2011er nicht aus den o.a. Gründen !!
OK wenn nur SFP1 beteiligt ist (die Konfig sagt aber was anderes, eth 2, 3, 4, 5 und 10 !) ist das natürlich kein Thema !
Dann hat das natürlich keinerlei Auswirkung da hast du recht.
Da ja kabelgebunden alle VLANs sauber funktionieren, kann es einzig nur der WLAN Part, also die fehlende Zuordnung der WLAN Interfaces tagged oder untagged auf die Bridge sein.
Wenn du sagts "WLAN klappt ja noch nicht" meinst du nur das einzelne WLAN.
Alle anderen MSSID WLANs funktionieren oder gehts da auch nicht ?
Sehen tust du doch alle MSSID WLANs am Client, oder ?
OK wenn nur SFP1 beteiligt ist (die Konfig sagt aber was anderes, eth 2, 3, 4, 5 und 10 !) ist das natürlich kein Thema !
Dann hat das natürlich keinerlei Auswirkung da hast du recht.
Da ja kabelgebunden alle VLANs sauber funktionieren, kann es einzig nur der WLAN Part, also die fehlende Zuordnung der WLAN Interfaces tagged oder untagged auf die Bridge sein.
Wenn du sagts "WLAN klappt ja noch nicht" meinst du nur das einzelne WLAN.
Alle anderen MSSID WLANs funktionieren oder gehts da auch nicht ?
Sehen tust du doch alle MSSID WLANs am Client, oder ?
Hi aqui,
ich habe immer einen "untagged" Port auf dem RB konfiguriert um ggf. mal an die VLANs zu kommen, falls ich mich auf den Ciscos aussperre. Da ich noch immer übe, kann das ja mal sein.
Allerdings funktionieren alle Ports auf dem RB reibungslos. d.h. die entsprechenden Subnetzte sind an den Ports 2,3,4,5 erreichbar, was mich jetzt schon etwas wundert. Ist hier aber momentan auch egal, der cap hängt am Cisco über SFP.
Ich sehe alle SSIDs auf meinen Clients (Windows, Android), kann mich aber nur mit VLAN60 verbinden. Bei allen anderen Versuchen klappt es nicht und die WLAN-Clients bleiben beim IP-Request hängen. Auch das Eintragen einer statischen IP aus dem VLAN70 (Gast) bringt nichts. Die Verbindung kommt nicht zu stande.
Ich habe am WE noch Einiges versucht. U.a. habe ich die CAP Interfaces den Bridge Posts br_vlan hinzugefügt. Das hatte ich irgendwo im Mikrotik Forum gelesen. Aber auch das bringt nichts.
Ist es denn tatsächlich so, dass ich die cap-Interfaces auch als "tagged member" unter "interface bridge vlan" hinzufügen muss? Das ist mir noch nicht klar und bevor ich hier alles noch mal platt mache, möchte ich sicher sein, dass ich auch alles richtig konfiguriert habe.
Danke und Gruß,
Christian
ich habe immer einen "untagged" Port auf dem RB konfiguriert um ggf. mal an die VLANs zu kommen, falls ich mich auf den Ciscos aussperre. Da ich noch immer übe, kann das ja mal sein
.Allerdings funktionieren alle Ports auf dem RB reibungslos. d.h. die entsprechenden Subnetzte sind an den Ports 2,3,4,5 erreichbar, was mich jetzt schon etwas wundert. Ist hier aber momentan auch egal, der cap hängt am Cisco über SFP.
Ich sehe alle SSIDs auf meinen Clients (Windows, Android), kann mich aber nur mit VLAN60 verbinden. Bei allen anderen Versuchen klappt es nicht und die WLAN-Clients bleiben beim IP-Request hängen. Auch das Eintragen einer statischen IP aus dem VLAN70 (Gast) bringt nichts. Die Verbindung kommt nicht zu stande.
Ich habe am WE noch Einiges versucht. U.a. habe ich die CAP Interfaces den Bridge Posts br_vlan hinzugefügt. Das hatte ich irgendwo im Mikrotik Forum gelesen. Aber auch das bringt nichts.
Ist es denn tatsächlich so, dass ich die cap-Interfaces auch als "tagged member" unter "interface bridge vlan" hinzufügen muss? Das ist mir noch nicht klar und bevor ich hier alles noch mal platt mache, möchte ich sicher sein, dass ich auch alles richtig konfiguriert habe.
Danke und Gruß,
Christian
Moin,
ich glaube, ich habe es gefunden
Und zwar fehlte am cAP die Einstellung "set bridge=bridge", warum auch immer!
/interface wireless cap
set bridge=bridge certificate=request discovery-interfaces=ether1 enabled=yes \
interfaces=wlan1 lock-to-caps-man=yes static-virtual=yes
Jetzt scheint es zu klappen, ich teste noch ein wenig.
Christian
ich glaube, ich habe es gefunden
Und zwar fehlte am cAP die Einstellung "set bridge=bridge", warum auch immer!
/interface wireless cap
set bridge=bridge certificate=request discovery-interfaces=ether1 enabled=yes \
interfaces=wlan1 lock-to-caps-man=yes static-virtual=yes
Jetzt scheint es zu klappen, ich teste noch ein wenig.
Christian
Im MT CLI klingt das recht abstrakt. Da wäre mal ein WinBox Screenshot erhellender.
Aber egal...wenns jetzt klappt wäre das ja gut
Aber egal...wenns jetzt klappt wäre das ja gut
Hi aqui,
scheint jetzt zu gehen. Ich habe von der fehlenden Einstellung des cAP einen Screenshot angefügt:
Allerdings habe ich noch eine Verständnisfrage zu "Local Forwarding". Vielleicht kannst Du mich da mal aufklären:
Folgendes Szenario:
RB3011:
cAP1:
cAP2:
Wenn ich es richtig verstehe, dann dürfte folgendes passieren:
Das würde dann bedeuten, dass ich auf jedem cAP die gleichen FW regeln implementiren müsste, wie auf dem RB3011. Alternativ "Local Forwarding" abschalten. Dann greifen die zentralen Regeln des RB3011 für alle Subnetze. Ist das tatsächlich so?
Christian
scheint jetzt zu gehen. Ich habe von der fehlenden Einstellung des cAP einen Screenshot angefügt:
Allerdings habe ich noch eine Verständnisfrage zu "Local Forwarding". Vielleicht kannst Du mich da mal aufklären:
Folgendes Szenario:
- auf dem RB3011 sind Firewall-Regeln aktiv, um zu verhindern, dass Clients in VLAN60 und Clients in VLAN70 untereinander nicht kommunizieren dürfen
- auf den cAPs ist "local Forwarding" aktiv:
RB3011:
- ether2=VLAN60 -> Client1
- ether3=VALN70 -> Client2
cAP1:
- WLAN1=VLAN60 -> Client3
- WLAN2=VLAN70 -> Client4
cAP2:
- WLAN1=VLAN60 -> Client5
- WLAN2=VLAN70 -> Client6
Wenn ich es richtig verstehe, dann dürfte folgendes passieren:
- Client1 und Client2 können nicht untereinander kommunizieren, da FW auf RB3011
- Client3 und Client4 können untereinander kommunizieren, da keine FW auf cAP1
- Client5 und Client6 können untereinander kommunizieren, da keine FW auf cAP2
- Client3 und Client6 können nicht untereinander kommunizieren, da FW auf RB3011
- Client4 und Client5 können nicht untereinander kommunizieren, da FW auf RB3011
- Client2, Client4 und Client6 können untereinander kommunizieren, da gleiches Subnet
- Client1, Client3 und Client5 können untereinander kommunizieren, da gleiches Subnet
Das würde dann bedeuten, dass ich auf jedem cAP die gleichen FW regeln implementiren müsste, wie auf dem RB3011. Alternativ "Local Forwarding" abschalten. Dann greifen die zentralen Regeln des RB3011 für alle Subnetze. Ist das tatsächlich so?
Christian
Ja das stimmt.
Wenn du zentrale Regeln hast ist es taktisch ggf. besser doch tunneled zu arbeiten, da dann der gesamte WLAN Traffic zentral zum 3011er getunnelt wird, dort zentral gefiltert wird und an die Switch Hardware übertragen.
Wenn du Local Forwarding machst hast du zwar die Tunnel Gesichte nicht mehr musst aber die Filter überall da wo du routest extra aufsetzen.
Ggf. ist der Tunneld morde dann bequemer um den Konfig Aufwand niedrig zu halten. Wenn du moderaten WLAN Traffic hast sind auch die Performance Einbußen verschmerzbar.
Wenn du zentrale Regeln hast ist es taktisch ggf. besser doch tunneled zu arbeiten, da dann der gesamte WLAN Traffic zentral zum 3011er getunnelt wird, dort zentral gefiltert wird und an die Switch Hardware übertragen.
Wenn du Local Forwarding machst hast du zwar die Tunnel Gesichte nicht mehr musst aber die Filter überall da wo du routest extra aufsetzen.
Ggf. ist der Tunneld morde dann bequemer um den Konfig Aufwand niedrig zu halten. Wenn du moderaten WLAN Traffic hast sind auch die Performance Einbußen verschmerzbar.
Hi aqui,
danke für die Aufklärung, allerdings verhält sich das System so, als würden die RB3011 Rules gezogen. Ich habe das eben mal getestet:
Auf dem Android-Tab habe ich einen ssh-Server installiert und konnte von dem Windows Rechner per putty nicht auf den Androiden zugreifen. Das soll ja auch so sein.
Erst als ich auf meinem RB3011 folgende Rule implementiert habe, funktionierte das:
Wobei die Subnetze VLAN70 und VLAN60 in der Adressliste "VlanFriends" aufgeführt sind. Ich habe auch noch mal den Datapath gecheckt. Da ist definitiv "local forwarding" angeklickt.
Komisch, oder?
Christian
danke für die Aufklärung, allerdings verhält sich das System so, als würden die RB3011 Rules gezogen. Ich habe das eben mal getestet:
Auf dem Android-Tab habe ich einen ssh-Server installiert und konnte von dem Windows Rechner per putty nicht auf den Androiden zugreifen. Das soll ja auch so sein.
Erst als ich auf meinem RB3011 folgende Rule implementiert habe, funktionierte das:
/ip firewall filter add action=accept chain=forward dst-address-list=VlanFriends in-interface-list=LAN src-address-list=VlanFriends comment="Allow inter VLAN communication with VLAN friends" Wobei die Subnetze VLAN70 und VLAN60 in der Adressliste "VlanFriends" aufgeführt sind. Ich habe auch noch mal den Datapath gecheckt. Da ist definitiv "local forwarding" angeklickt.
# CAPsMAN - Datapath
/caps-man datapath add bridge=br_vlan local-forwarding=yes name=vlan60 vlan-id=60 vlan-mode=use-tag
/caps-man datapath add bridge=br_vlan local-forwarding=yes name=vlan70 vlan-id=70 vlan-mode=use-tagKomisch, oder?
Christian
Hallo aqui,
also da passt was mit dem "Local Forwarding" noch nicht zusammen.
Wenn ich im Datapath das "Local Forwarding" deaktiviere, kann ich mich mit dem WLAN nicht mehr verbinden. Ich hatte erwartet, dass der komplette Datenverkehr über die RB3011 Firewall getunnelt wird und auch die Regeln vom RB3011 gezogen werden. Das passiert aber nicht, im Gegenteil, ich kann hier überhaupt keine WLAN-Verbindung aufbauen.
Es ist wirklich so, dass bei aktivem "Lokal Forwarding" im Datapath die FW Regeln vom RB3011 zur Anwendung kommen. Das ist reproduzierbar. Wenn ich z.B. in den SONOS-FW-Regeln auf dem RB3011 das vlan60 aussperre (da laufen Controller drin) funktionieren die Controller im WLAN nicht mehr. Auch die o.a. "VlanFriends" funktionieren nur mit "Local Forwarding", heißt: Entferne ich die Regel "VLANFriedns" vom RB3011, kann kein Subnetz mit dem anderen sprechen, egal, ob verkabelt, oder WLAN.
Ich meine irgendwo gelesen zu haben, dass dieses auch im CAPsMAN aktiv sein muss, wenn man VLAN Filtering einsetzt, aber ich kann das auch falsch verstanden haben.
Wenn Deine letzte Aussage zu "Local Forwaring" richtig ist, dann müssten die WLANs sich trotz der Regeln auf dem RB3011 sehen, da keine FW regeln auf den cAPs sind. Aber genau das passiert eben nicht. Ist hier noch der Wurm drin, in meiner Konfg?
Was meinst Du dazu?
Christian
also da passt was mit dem "Local Forwarding" noch nicht zusammen.
Wenn ich im Datapath das "Local Forwarding" deaktiviere, kann ich mich mit dem WLAN nicht mehr verbinden. Ich hatte erwartet, dass der komplette Datenverkehr über die RB3011 Firewall getunnelt wird und auch die Regeln vom RB3011 gezogen werden. Das passiert aber nicht, im Gegenteil, ich kann hier überhaupt keine WLAN-Verbindung aufbauen.
Es ist wirklich so, dass bei aktivem "Lokal Forwarding" im Datapath die FW Regeln vom RB3011 zur Anwendung kommen. Das ist reproduzierbar. Wenn ich z.B. in den SONOS-FW-Regeln auf dem RB3011 das vlan60 aussperre (da laufen Controller drin) funktionieren die Controller im WLAN nicht mehr. Auch die o.a. "VlanFriends" funktionieren nur mit "Local Forwarding", heißt: Entferne ich die Regel "VLANFriedns" vom RB3011, kann kein Subnetz mit dem anderen sprechen, egal, ob verkabelt, oder WLAN.
Ich meine irgendwo gelesen zu haben, dass dieses auch im CAPsMAN aktiv sein muss, wenn man VLAN Filtering einsetzt, aber ich kann das auch falsch verstanden haben.
Wenn Deine letzte Aussage zu "Local Forwaring" richtig ist, dann müssten die WLANs sich trotz der Regeln auf dem RB3011 sehen, da keine FW regeln auf den cAPs sind. Aber genau das passiert eben nicht. Ist hier noch der Wurm drin, in meiner Konfg?
Was meinst Du dazu?
Christian
Na ja die Frage ist wie das Capsman das sieht. Es ist ja quasi so das sich der Controller ja dann das Config Interface der cAPs "zieht".
Virtuell sieht es dann so aus als ob das regelwerk auf dem Controller ist, physisch pusht er es dann aber auf den cAP.
Das ist aber jetzt nur eine Vermutung da ich ein ACL Regelwerk bis dato selber mit Capsman noch nicht eingerichtet habe.
Ist wohl mal Zeit für einen Laboraufbau
Virtuell sieht es dann so aus als ob das regelwerk auf dem Controller ist, physisch pusht er es dann aber auf den cAP.
Das ist aber jetzt nur eine Vermutung da ich ein ACL Regelwerk bis dato selber mit Capsman noch nicht eingerichtet habe.
Ist wohl mal Zeit für einen Laboraufbau
Hi aqui,
Besten Dank für Dein Feedback!
Lass mich bitte an Deinen Laborergebnissen Teil haben!
Das interessiert mich schon sehr!
Gruß,
Christian
Besten Dank für Dein Feedback!
Lass mich bitte an Deinen Laborergebnissen Teil haben!
Das interessiert mich schon sehr!
Gruß,
Christian
Hallo,
ich muss an dieser Stelle noch mal eingreifen, da hier offenbar noch ein Problem vorliegt.
Wenn ich von einem Client, der im WLAN hängt (vlan60) auf einen anderen Client der per WLAN im selben VLAN hängt zugreifen möchte, funktioniert das nicht. Hier scheint der Verkehr nicht über den RB3011 geroutet zu werden. Offenbar liegt das am "Local Forwarding". Wenn ich das aber abschalte, dann werden meine VLANs untereinader aber nicht mehr geroutet. Also irgendrtwas ist mit meiner CAP-Konfig noch nicht sauber.
Daher die Frage;
Was genau muss ich tun, damit meine Vlans die per WLAN über die FW im RB3011 geroutet werden?
WLAN-Clients, die auf kabelgebundene VLAN-Clients zugreifen laufen sauber. Nur die Kommunikation zwischen zwei WLAN-Clients geht nicht. Ich bin etwas ratlos!
Christian
ich muss an dieser Stelle noch mal eingreifen, da hier offenbar noch ein Problem vorliegt.
Wenn ich von einem Client, der im WLAN hängt (vlan60) auf einen anderen Client der per WLAN im selben VLAN hängt zugreifen möchte, funktioniert das nicht. Hier scheint der Verkehr nicht über den RB3011 geroutet zu werden. Offenbar liegt das am "Local Forwarding". Wenn ich das aber abschalte, dann werden meine VLANs untereinader aber nicht mehr geroutet. Also irgendrtwas ist mit meiner CAP-Konfig noch nicht sauber.
Daher die Frage;
Was genau muss ich tun, damit meine Vlans die per WLAN über die FW im RB3011 geroutet werden?
WLAN-Clients, die auf kabelgebundene VLAN-Clients zugreifen laufen sauber. Nur die Kommunikation zwischen zwei WLAN-Clients geht nicht. Ich bin etwas ratlos!
Christian
auf einen anderen Client der per WLAN im selben VLAN hängt zugreifen möchte, funktioniert das nicht.
Hast du ggf. WLAN Client Isolation im WLAN aktiviert ?? Das sieht verdächtig danach aus.Endgeräte im gleichen IP Netz werden ja niemals geroutet !! Die kommunizieren direkt im Layer 2.
Das setzt natürlich voraus das du die WLANs mit den VLANs via Bridge verbunden hast und das die WLANs NICHT als dediziertes IP Netz betrieben werden ?!
Nur die Kommunikation zwischen zwei WLAN-Clients geht nicht.
Sehr sicher ist das die aktive Client Isolation.
Hallo aqui,
schön, dass Du wieder da bist und danke für Deine Antwort.
Wo genau finde ich die aktive Client Isolation im CapsMan?
Ist das dieser Schalter hier (Client to Client Forwarding), der aktiviert werden muss?
Danke und Gruß,
Christian
schön, dass Du wieder da bist und danke für Deine Antwort.
Wo genau finde ich die aktive Client Isolation im CapsMan?
Ist das dieser Schalter hier (Client to Client Forwarding), der aktiviert werden muss?
Danke und Gruß,
Christian
Nein, es ist das default-forwarding in den Wireless Settings:
https://mikrotik.com/testdocs/ros/2.9/interface/wireless.php
http://www.wirelessguru.it/en/mikrotik/capsman-abilitare-il-client-isol ...
https://mikrotik.com/testdocs/ros/2.9/interface/wireless.php
http://www.wirelessguru.it/en/mikrotik/capsman-abilitare-il-client-isol ...
Hi,
hm! jetzt verwirrst Du mich! In dem 2.Link steht doch bei CAPSMAN, dass man Client-to-Client Forwarding auf "no" setzten soll, wenn die Clients untereinander nicht reden dürfen. Demzufolge müsste ich es doch auf "yes" setzen in meinem CAPSMAN.
"default-forwarding " finde ich im CAPSMAN nicht!
Christian
NACHTRAG:
Habe Client to Client Forwarding aktiviert und es klappt. Daran hat es offenbar gelegen. BEsten Dank.
hm! jetzt verwirrst Du mich! In dem 2.Link steht doch bei CAPSMAN, dass man Client-to-Client Forwarding auf "no" setzten soll, wenn die Clients untereinander nicht reden dürfen. Demzufolge müsste ich es doch auf "yes" setzen in meinem CAPSMAN.
"default-forwarding " finde ich im CAPSMAN nicht!
Christian
NACHTRAG:
Habe Client to Client Forwarding aktiviert und es klappt. Daran hat es offenbar gelegen. BEsten Dank.
Alles wird gut
...und hier gehts weiter:
WLAN: VLAN-Zuordnung anhand Radius-Eigenschaften? MikroTik CAPsMAN
...und hier gehts weiter:
WLAN: VLAN-Zuordnung anhand Radius-Eigenschaften? MikroTik CAPsMAN
Guten Abend,
ich habe ein ähnliches Problem wie Spartacus, dass ich mit dem Mikrotik capsman meine Wlan-Clients unterschiedlichen Vlans zuweisen möchte. Abweichend möchte ich dies aber mit nur einer SSID realisieren und die Clients anhand der MAC dem jeweiligen Vlan zuweisen (Nutzung der CAPsMAN AccessList). Nicht bekannte MACs werden rejected oder kommen in ein GAST Wlan - weis ich nicht nicht genau.
Vlans habe ich nach den Anleitungen von @aqui eingerichtet und funktionieren auch separat. Also im Moment kann ich alle Clients entweder Vlan200 oder Vlan222 zuweisen. Aber Client1 Vlan200 und Client2 Vlan222 geht nicht <--- das ist meine Frage wie man das macht und hoffe auf eure Hilfe.
Anbei ein paar Screenshots:
Hier kann Client1 keine IP beziehen aber Cliet2 - habe auch schon sämtliche Varianten von VlanMode in der AccessList probiert
DHCP und Firewall Regeln soll die vorgeschaltete pfsense übernehmen
Schon ein Mal vielen Dank für eure Hilfe !
Gruß Phil
ich habe ein ähnliches Problem wie Spartacus, dass ich mit dem Mikrotik capsman meine Wlan-Clients unterschiedlichen Vlans zuweisen möchte. Abweichend möchte ich dies aber mit nur einer SSID realisieren und die Clients anhand der MAC dem jeweiligen Vlan zuweisen (Nutzung der CAPsMAN AccessList). Nicht bekannte MACs werden rejected oder kommen in ein GAST Wlan - weis ich nicht nicht genau.
Vlans habe ich nach den Anleitungen von @aqui eingerichtet und funktionieren auch separat. Also im Moment kann ich alle Clients entweder Vlan200 oder Vlan222 zuweisen. Aber Client1 Vlan200 und Client2 Vlan222 geht nicht <--- das ist meine Frage wie man das macht und hoffe auf eure Hilfe.
Anbei ein paar Screenshots:
Hier kann Client1 keine IP beziehen aber Cliet2 - habe auch schon sämtliche Varianten von VlanMode in der AccessList probiert
DHCP und Firewall Regeln soll die vorgeschaltete pfsense übernehmen
Schon ein Mal vielen Dank für eure Hilfe !
Gruß Phil
Abweichend möchte ich dies aber mit nur einer SSID realisieren und die Clients anhand der MAC dem jeweiligen Vlan zuweisen
Es gibt mittlerweile ein detailiertes Foren Tutorial mit einem wasserdicht funktionierenden Setup für genau deine Anforderungen:Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik
Halte dich also genau da dieses Tutorial, dann kommt das auch sofort zum Fliegen.
Hi,
in deiner Anleitung läuft der Radius auf einer separaten Hardware (RasPi z.b. hast du geschrieben). Die zusätzliche HW wollte ich mit sparen und direkt auf dem MT laufen lassen. Unter MTs usermanager oder RADIUS habe ich nichts gefunden um die Clients zu definieren (also deren Vlan anhand der MAC).
Daher der Versuch über die AccessList
in deiner Anleitung läuft der Radius auf einer separaten Hardware (RasPi z.b. hast du geschrieben). Die zusätzliche HW wollte ich mit sparen und direkt auf dem MT laufen lassen. Unter MTs usermanager oder RADIUS habe ich nichts gefunden um die Clients zu definieren (also deren Vlan anhand der MAC).
Daher der Versuch über die AccessList
Das geht leider nicht, denn der Radius Server des Mikrotik ist kein vollständiger Radius Server und supportet dieses Feature leider NICHT. Er macht lediglich eine User Authorisierung mehr nicht und ist daher unbrauchbar dafür. Das kannst du also vergessen...
Hättest du das Tutorial nur einmal etwas aufmerksamer gelesen, dann hättest du das in den Kommentaren auch gefunden !
Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik
Aber du hast ja eine pfSense !!
Über die dortige Package Verwaltung kannst du einen FreeRadius dort nachinstallieren und der macht das dann mit links !
Alternative wäre noch ein NAS. QNAP und Synology z.B. ermöglichen die Installation eines Radius Servers (FreeRadius). Der Kollege @Spartacus hat es bei sich so gelöst.
Es gibt also mehrere gute Lösungen ohne extra Hardware.
Hättest du das Tutorial nur einmal etwas aufmerksamer gelesen, dann hättest du das in den Kommentaren auch gefunden !
Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik
Aber du hast ja eine pfSense !!
Über die dortige Package Verwaltung kannst du einen FreeRadius dort nachinstallieren und der macht das dann mit links !
Alternative wäre noch ein NAS. QNAP und Synology z.B. ermöglichen die Installation eines Radius Servers (FreeRadius). Der Kollege @Spartacus hat es bei sich so gelöst.
Es gibt also mehrere gute Lösungen ohne extra Hardware.
Nabend,
danke für den Hinweis im Kommentar. Habe es nun auf der pfsense zum "Fliegen" bekommen, dass die Clients nach MAC zu oder nicht zugelassen werden. Die Zuweisung zu dem VLAN macht diese aber nicht. Mit dieser Confi des MT CAP Interfaces
wird jeder Client in den Standard IP Bereich 192.168.20. gebracht (auf dem der Mikrotik AP läuft) und das obwohl ich in der sense
angegeben habe. Auch mit VLAN Mode - use tag und ohne VLAN ID passiert das gleiche
Wenn ich
definieren (oder respektive 222), dann kommen die Clients in VLAN200 oder eben VLAN222 - egal was ich in der Sense der MAC zugewiesen habe.
Dadurch dass entweder alle Clients dem VLAN222 und 200 manuell zuweisen kann, gehe ich von aus, dass die VLANS richtig eingerichtet sind. Aber weiter komme ich damit auch nicht
Wo liegt noch mein (Denk)-Fehler?
Danke im Voraus!
danke für den Hinweis im Kommentar. Habe es nun auf der pfsense zum "Fliegen" bekommen, dass die Clients nach MAC zu oder nicht zugelassen werden. Die Zuweisung zu dem VLAN macht diese aber nicht. Mit dieser Confi des MT CAP Interfaces
wird jeder Client in den Standard IP Bereich 192.168.20. gebracht (auf dem der Mikrotik AP läuft) und das obwohl ich in der sense
Wenn ich
Dadurch dass entweder alle Clients dem VLAN222 und 200 manuell zuweisen kann, gehe ich von aus, dass die VLANS richtig eingerichtet sind. Aber weiter komme ich damit auch nicht
Wo liegt noch mein (Denk)-Fehler?
Danke im Voraus!
Auch mit VLAN Mode - use tag und ohne VLAN ID passiert das gleiche
Das ist auch falsch, denn du darfst ja niemals statisch am AP das VLAN zuweisen. Das kann ja nur ausschliesslich dynmaisch passieren über den Radius !Relevant ist für die dynmaische Vergabe deine User Konfig Datei auf dem Radius Server. Bist du mal über die Shell auf die pfSense gegenagen und hast dir diese mal genau angesehen ??
Dort muss als Beispiel z.B. für die Mac Adresse 0022:FA7B:1234
0022:FA7B:1234 Cleartext-Password := "0022:FA7B:1234"
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Mikrotik-Wireless-VLANID := 10,
Mikrotik-Wireless-Forward := 1,
Mikrotik-Wireless-VLANID-type := 0
stehen. Der Radius Server benötigt dazu zwingend die Vendor spezifischen Attribute. Diese solltest du dem Radius Server mitgegeben haben. Ist das der Fall bei dir ?
Das ist auch falsch, denn du darfst ja niemals statisch am AP das VLAN zuweisen. Das kann ja nur ausschliesslich dynmaisch passieren über den Radius !
Das war der Test ob die VLANs überhaupt funktionieren bzw. richtig konfiguriert sind.Die ausschliessliche Konfi über die WebGui hat diesen Eintrag erzeugt <-- Sowohl in /usr/local/etc/raddb/users als auch in /usr/local/etc/raddb/authorized_macs
aa-bb-cc-11-22-33 Cleartext-Password := "aa-bb-cc-11-22-33"
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-ID = "200"
Habe deine Anpassungen vorgenommen und in geändert (authorized_macs und users):
aa-bb-cc-11-22-33 Cleartext-Password := "aa-bb-cc-11-22-33"
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Mikrotik-Wireless-VLANID := 200,
Mikrotik-Wireless-Forward := 1,
Mikrotik-Wireless-VLANID-type := 0
Wenn ich die users oder MAC Konfi über ssh vornehme tauchen diese nicht in der WebGui auf, ist das ein normales Verhalten?
Selbst mit den Einträgen nach deinem Vorbild wird die o.g. MAC wieder in den Standard IP Bereich 20 geworfen.
Weis nicht ob es relevant ist, aber in der pfsense ist Plain MAC Auth aktiviert
Ja, das Problem ist das Mikrotik Vendor spezifische Attribute nutzt die man so über das GUI nicht eingeben kann und entsprechend unterdrückt werden. Man muss deshalb die Users Datei immer manuelle anpassen und besser auch noch eine Sicherung mit users.backup in das Verzeichnis schreiben, denn klickt man im GUI versehentlich mal auf "Save" überschreibt er die ganzen Einträge. Ein kleiner Wermutstropfen der aber verschmerzbar ist. Man kann über einen Cron Job ja stündlich die Users zurückkopieren...
Logischerweise ist der dann gesendete Username aabb:cc11:22-33 ein völlig anderer als aa-bb-cc-11-22-33 der in deinem Radius steht und die Authentisierung (und damit auch die VLAN Zuweisung) schlägt dann natürlich sofort fehl !
Das musst du also anpassen ! Zeigt aber auch das deine Authentisierung klappt !
wird die o.g. MAC wieder in den Standard IP Bereich 20 geworfen.
Das ist vermutlich auch normal wenn du der Tutorial Konfig geforlgt bist und das dort gewählte Format der Mac Adresse die der Radius überträgt konfiguriert hast !Das musst du also anpassen ! Zeigt aber auch das deine Authentisierung klappt !
War die ganze Zeit so eingestellt:
Bisher hatte ich bei der AccessList keine MAC angegeben:
Wollte mal probieren die MAC eines Clients im Format aa-bb-cc-11-22-33 im Feld "MAC Address:" anzugeben, aber beim Bestätigen werden die - durch : ersetzt.
Bisher hatte ich bei der AccessList keine MAC angegeben:
Wollte mal probieren die MAC eines Clients im Format aa-bb-cc-11-22-33 im Feld "MAC Address:" anzugeben, aber beim Bestätigen werden die - durch : ersetzt.
Table of contents
pfSense
Ein Testsetup auf der pfSense mit dem FreeRadius Package klappt fehlerlos!Es erfordert etwas "Handarbeit", klappt dann aber fehlerfrei.
Mit den folgenden ToDos bekommst du das sofort zum Fliegen...
Basissetup der Firewall
Die pfSense gibt bei der Insallation des Freeradius Packages eine entsprechende Hinweismeldung die zu beachten ist:EAP certificate configuration is required before using the package.
Visit System > Cert. Manager and create a CA and a server certificate.
After that, visit Services > FreeRADIUS > EAP tab and complete
the 'Certificates for TLS' section (and, optionally, also the 'EAP-TLS' section.) Wie das geht wird im Detail im pfSense VPN Tutorial erklärt!
Gleiches gilt auch für die OPNsense.
Einrichtung der Benutzer
Mikrotik erfordert im Gegensatz zu anderen WLAN AP für die dynamische VLAN Zuweisung (und NUR für die dynamische VLAN Zuweisung im WLAN!) ein herstellerspezifisches Attribut was dem WLAN Username zusätzlich konfiguriert werden muss Im Feld Additional RADIUS Attributes (REPLY-ITEM)
Optional: Separate User Datei über den Shell Zugang erstellen
Wer sich das ersparen will kann alternativ auch eine separate, selber erstellte User Datei verwenden was aber deutlich aufwändiger ist als das Setup über das GUI oben.Dazu connectest man die pfSense über das serielle Terminal oder von extern über den SSH Shell Zugang mit PuTTY und erstellst mit dem vi Editor eine separate User Datei z.B. users.test
Noch einfacher ist es diese Datei mit einem Editor eigener Wahl wie z.B. Notepad++ vorher sauber zu editieren und dann ganz einfach mit einem grafischen Copy Tool wie z.B. dem Klassiker WinSCP per Drag and Drop direkt auf die Firewall zu kopieren. Am Besten ins Verzeichnis /usr/local/etc/raddb Wo die originale User Datei ist.
[root@pfSense.test.home.arpa]/usr/local/etc/raddb: cat users.test
# Mikrotik Mac Auth and dyn. VLAN
# Mac Format XXXX:XXXX:XXXX
#
0022:FA7B:1234 Cleartext-Password := "0022:FA7B:1234"
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Mikrotik-Wireless-VLANID := 10,
Mikrotik-Wireless-Comment = "Laptop"
#
0021:857E:5678 Cleartext-Password := "0021:857E:5678"
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Mikrotik-Wireless-VLANID := 20,
Mikrotik-Wireless-Comment = "Smartphone"
#
DEFAULT Cleartext-Password := "%{User-Name}"
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Mikrotik-Wireless-VLANID := 99,
Mikrotik-Wireless-Comment = "unknown" Ansonsten mit "#" auskommentieren oder ganz weglassen, dann werden unregistrierte Benutzer generell abgewiesen.
Users Datei im GUI anpassen
Ist das erledigt kannst du mit einem Trick die original User Datei anpassen. FreeRadius erlaubt mit dem "$Include" Parameter externe, eigene User Dateien zu Importieren. Das hebelt elegant das Überschreiben der User Konfig Datei im GUI aus. Du legst einen einzigen exotischen Dummy User dort an und in den Parametern definierst du deine eigene User Datei mit $INCLUDE /usr/local/etc/raddb/users.test was dann so aussieht:
Der Rest ist dann Standard
Interfaces für den Radius Zugriff aktivieren
Im Produktivnetz sollte man unter Interface IP immer die dedizierte IP des lokalen Ports eintragen über den der Radius Request auf die pfSense eingeht. In der Regel ist das einer der lokalen LAN Ports.
Natürlich sollte dort auch eine entsprechende Regel existieren die den Radius Request passieren lässt.
Der "*" erlaubt den Zugang über alle Interfaces, also auch den WAN Port was sicher keine gute Idee ist !
Check ob der Radius Server aktiv ist
Das wars !
Das rennt dann fehlerfrei.
Zusatzinfo Troubleshooting
Natürlich kann man auch wunderbar den Radius Server auf der pfSense troubleshooten wenn das einmal erforderlich sein sollte !Dazu geht man wieder auf die Shell über Seriell oder SSH mit PuTTY und checkt mit ps ax | grep radiusd welche Process ID der Radius Server hat.
[root@TestSense.lab.home.arpa]/usr/local/etc/raddb: ps ax | grep radiusd
87534 - Is 0:00.31 /usr/local/sbin/radiusd
88924 u0 R+ 0:00.00 grep radiusd
[root@TestSense.lab.home.arpa]/usr/local/etc/raddb: kill 87534 Dann startet man wie beim Debuggen üblich mit radiudsd -X den FreeRadius manuell im Debugging Mode und kann dann anhand der Meldungen sehr genau sehen was schief geht. Wenn denn überhaupt etwas schief geht...
OPNsense Radius Plugin
Achtung!: bei dynamischen VLANs mit OPNsense FreeRadius Plugin:OPNSense FreeRadius Server-MAC Authentication-dynamische VLAN Zuweisung
Die OPNsense kommt mit ihrem Radius Plugin schon fertig daher ohne die o.a. Klimmzüge:
Habe deine Konfi übernommen. Du hast ja bei den Argumenten lediglich zwei Stück weggelassen, oder habe ich was übersehen.
Leider funktioniert es wohl erst zum Teil:
Output von radiusd -X
Macht es hier einen Unterschied wenn die MAC vollständig groß geschrieben ist oder klein? In der pfsense muss ich z.B. bei den MACs darauf achten, dass die Schreibweise mit denen der users übereinstimmt.
Der Client kann sich zwar beim Radius identifizieren lassen, aber der bekommt eine IP zugewiesen (oder bestimmt sie selber ?!) die nirgends konfiguriert ist 169.254.232.210
So als würde der Client nicht beim DHCP Server (laufen bei mir alle auf der pfsense) raus kommen. Auch führt die pfsense den Client im Moment nicht auf. In der Registration Table im Mikrotik ist der Client mit groß geschriebener MAC und mit ":" anstatt "-" aufgeführt, aber ohne EAP Identity.
CAPsMAN - AAA - MAC Format habe ich mit XX-XX-XX-XX-XX-XX angegeben
Leider funktioniert es wohl erst zum Teil:
Output von radiusd -X
[...]
rlm_counter: Entering module authorize code
rlm_counter: Could not find Check item value pair
(0) [forever] = noop
(0) if (&request:Calling-Station-Id == &control:Calling-Station-Id) {
(0) ERROR: Failed retrieving values required to evaluate condition
(0) [expiration] = noop
(0) [logintime] = noop
(0) [pap] = updated
(0) } # authorize = updated
(0) Found Auth-Type = PAP
(0) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(0) Auth-Type PAP {
(0) pap: Login attempt with password
(0) pap: Comparing with "known good" Cleartext-Password
(0) pap: User authenticated successfully
(0) [pap] = ok
(0) } # Auth-Type PAP = ok
(0) # Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/default
(0) post-auth {
(0) update {
(0) No attributes updated for RHS &session-state:
(0) } # update = noop
(0) [exec] = noop
(0) policy remove_reply_message_if_eap {
(0) if (&reply:EAP-Message && &reply:Reply-Message) {
(0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE
(0) else {
(0) [noop] = noop
(0) } # else = noop
(0) } # policy remove_reply_message_if_eap = noop
(0) } # post-auth = noop
(0) Login OK: [AA-BB-CC-DD-EE-FF] (from client MT_hAPac2 port 0 cli aa-bb-cc-dd-ee-ff)
(0) Sent Access-Accept Id 195 from 192.168.10.2:1812 to 192.168.20.2:60641 length 0
(0) Tunnel-Type = VLAN
(0) Tunnel-Medium-Type = IEEE-802
(0) Mikrotik-Wireless-VLANID = 200
(0) Mikrotik-Wireless-Comment = "client"
(0) Finished request
Waking up in 4.9 seconds.
(0) Cleaning up request packet ID 195 with timestamp +4
Ready to process requestsMacht es hier einen Unterschied wenn die MAC vollständig groß geschrieben ist oder klein? In der pfsense muss ich z.B. bei den MACs darauf achten, dass die Schreibweise mit denen der users übereinstimmt.
Der Client kann sich zwar beim Radius identifizieren lassen, aber der bekommt eine IP zugewiesen (oder bestimmt sie selber ?!) die nirgends konfiguriert ist 169.254.232.210
So als würde der Client nicht beim DHCP Server (laufen bei mir alle auf der pfsense) raus kommen. Auch führt die pfsense den Client im Moment nicht auf. In der Registration Table im Mikrotik ist der Client mit groß geschriebener MAC und mit ":" anstatt "-" aufgeführt, aber ohne EAP Identity.
CAPsMAN - AAA - MAC Format habe ich mit XX-XX-XX-XX-XX-XX angegeben
Du hast ja bei den Argumenten lediglich zwei Stück weggelassen, oder habe ich was übersehen.
Nein das hast du messerscharf richtig beobachtet ! Diese beiden Parameter braucht man nicht, weil das die Default Werte sind auf die sie so oder so gesetzt sind. Sie sind also obsolet und machen die Konfig einfacher und übersichtlicher.
Ich habe das wasserdicht getestet.
Macht es hier einen Unterschied wenn die MAC vollständig groß geschrieben ist oder klein?
Ja, er FreeRadius unterscheidet bei den Usernamen Groß- Kleinschreibung.In der pfSense werkelt übrigens genau so einer wie im Tutorial. In der Beziehung ist das allso völlig gleich.
die nirgends konfiguriert ist 169.254.232.210
Ist eine APIPA oder jetzt ZeroConf IP. Guckst du hier:https://de.wikipedia.org/wiki/Zeroconf#Automatische_IP-Zuweisung
Sollte man eigentlich kennen als Netzwerker...
Der Grund ist das der Client keinen DHCP Server "sieht" in dem Segment. Er schickt mehrere DHCP Requests und wenn in einer bestimmten Timeout Zeit keine Antworten kommen vergibt der Port sich eine ZerConf IP selber.
Vermutlich hast du vergessen den Switchport wo der AP angeschlossen ist für das VLAN 200 zu taggen ?! Kann das sein ? Oder du hast vergessen in das VLAN 200 einen DHCP Server zu legen. Hast du das vorher mal wasserdicht an einem Kupferport ausprobiert das da VLAN 200 IPs via DHCP kommen ?
CAPsMAN - AAA - MAC Format habe ich mit XX-XX-XX-XX-XX-XX angegeben
OK, dann stimmt das Format ja auch ! Würde mit ":" statt "-" dazwischen auch fehlschlagen. Der Client wird ja auch fehlerfrei authentisiert: Sent Access-Accept Id 195 from 192.168.10.2:1812 to 192.168.20.2:60641 length 0 !Vermutlich irgendwo ein Tagging Fehler. Da kann man aber jetzt ohne weitere Konfig Info vom AP Port und pfSense Port jetzt erstmal nur wild raten...
Was den Fehler: "ERROR: Failed retrieving values required to evaluate condition" anbetrifft ist der vermutlich nur kosmetisch und kannst du ignorieren. Ich lasse eben mal auf meiner pfSense nochmal den Debugger laufen und checke das ob das da identisch ist.
Vermutlich hast du vergessen den Switchport wo der AP angeschlossen ist für das VLAN 200 zu taggen ?! Kann das sein ? Oder du hast vergessen in das VLAN 200 einen DHCP Server zu legen. Hast du das vorher mal wasserdicht an einem Kupferport ausprobiert das da VLAN 200 IPs via DHCP kommen ?
Also ich probeweise den AP ein schatisches VLAN zugewiesen habe, bekam der Client die entsprechende IP aus dem 200er VLAN. Die pfsense führte ihn auch auf (damals wars ein WLan Client). Habe eben auch am Switch einen Port auf Vlan 200 getagget und der Kupferclient bekam auch eine IP aus dem 200Vlan. DHCP läuft und verteilt in diesen beiden Fällen fleissig IPs...
Wenn ich einen Wlan Client mit dem "dynamischen Wlan" verbinde zeigt die sense mir lediglich folgende Meldung bei den DHCP SystemLogs:
May 31 23:06:18 dhcpd DHCPOFFER on 192.168.200.101 to aa:bb:cc:dd:ee:ff (Smartphone) via igb1.200
May 31 23:06:18 dhcpd DHCPDISCOVER from aa:bb:cc:dd:ee:ff (Smartphone) via igb1.200 Keine weiteren Meldungen zu dem Vorgang
Mmmhh, das zeigt aber wiederum das vom AP das richtige VLAN zugeordnet wurde und auch dein Client im richtigen VLAN gelandet ist.
Sprich also die dynamische VLAN Zuordnung dieses Clients mit der Mac aa:bb:cc:dd:ee:ff ist fehlerfrei richtig gelaufen und der Client hat dann auch nach erfolgreicher Authentisierung im VLAN 200 nach einer DHCP Adresse gefragt mit einem DHCP Request. Das ist der DHCP Discover oben.
Daraufhin hat die pfSense bzw. deren DHCP Server dort auch im VLAN 200 mit einem DHCP Offer geantwortet und dem Client die IP 192.168.200.101 aus dem VLAN 200 zugeteilt.
Eigentlich müsste der Client dann diese VLAN 200 IP auch bekommen haben. Ist das der Fall ?
Kannst du dann mit dem Smartphone die VLAN 200 IP Adresse der pfSense pingen ? Z.B. mit den HE.net Tools:
https://apps.apple.com/de/app/he-net-network-tools/id858241710
https://play.google.com/store/apps/details?id=net.he.networktools&hl ...
Ein Wireshark Trace auf dem WLAN Port eines Testlaptops hier in VLAN 10 zeigt einen klassischen DHCP Verlauf nachdem der Client authentisiert und das richtige VLAN zugewiesen wurde:
Die rlm_counter Meldungen kommen hier übrigens auch identisch zu deinen aber die sind, wie vermutet, nur kosmetisch. Funktionieren tut es trotzdem.
Was noch wichtig ist, ist dein Design. Wer macht das CapsMan Controlling und wie sind AP und pfSense im Layer 2 verbunden bzw. mit welchem Switch ?
Layer 3 also das Routing macht ja komplett die pfSense, deshalb darfst du auch einen L2 Switch dazwischen maximal eine Management IP vergeben haben. Das Design wäre nochmal wichtig zu verstehen.
Sprich also die dynamische VLAN Zuordnung dieses Clients mit der Mac aa:bb:cc:dd:ee:ff ist fehlerfrei richtig gelaufen und der Client hat dann auch nach erfolgreicher Authentisierung im VLAN 200 nach einer DHCP Adresse gefragt mit einem DHCP Request. Das ist der DHCP Discover oben.
Daraufhin hat die pfSense bzw. deren DHCP Server dort auch im VLAN 200 mit einem DHCP Offer geantwortet und dem Client die IP 192.168.200.101 aus dem VLAN 200 zugeteilt.
Eigentlich müsste der Client dann diese VLAN 200 IP auch bekommen haben. Ist das der Fall ?
Kannst du dann mit dem Smartphone die VLAN 200 IP Adresse der pfSense pingen ? Z.B. mit den HE.net Tools:
https://apps.apple.com/de/app/he-net-network-tools/id858241710
https://play.google.com/store/apps/details?id=net.he.networktools&hl ...
Ein Wireshark Trace auf dem WLAN Port eines Testlaptops hier in VLAN 10 zeigt einen klassischen DHCP Verlauf nachdem der Client authentisiert und das richtige VLAN zugewiesen wurde:
Die rlm_counter Meldungen kommen hier übrigens auch identisch zu deinen aber die sind, wie vermutet, nur kosmetisch. Funktionieren tut es trotzdem.
Was noch wichtig ist, ist dein Design. Wer macht das CapsMan Controlling und wie sind AP und pfSense im Layer 2 verbunden bzw. mit welchem Switch ?
Layer 3 also das Routing macht ja komplett die pfSense, deshalb darfst du auch einen L2 Switch dazwischen maximal eine Management IP vergeben haben. Das Design wäre nochmal wichtig zu verstehen.
Eigentlich müsste der Client dann diese VLAN 200 IP auch bekommen haben. Ist das der Fall ?
Nein der Client bekommt die o.g. ZeroConf IP: 169.254.232.210Kannst du dann mit dem Smartphone die VLAN 200 IP Adresse der pfSense pingen ?
Nein kann die 200.1 nicht pingenHabe dem VLAN200 auch in der Sense eine "any any" Regel erlaubt
Zum Aufbau:
- Habe einen Mikrotik hAPAC2 der sowohl den CAPsMAN Controller macht als auch mit seinen WLan Interfaces den CAP
- Davor hängt direkt die pfsense, die DHCP und Firewall Regeln macht
Könnte hier ein Fehler sein, dass das CAP Interface nicht untagged sein muss? Hier sieht man auch auf ether4 den gestrigen Test ob die Kupferverbindung dem Client eine 200er IP aus dem VLAN200 zuweist. Das hatte funktioniert.
Problem ist klar !
Du hast die Management IP des hAP ac direkt an die Bridge selber gehängt. Das geht so nicht mehr in einem VLAN Setup der Bridge (VLAN Filtering aktiv) !
Du musst ein entsprechendes VLAN Interface anlegen mit der Management VLAN ID und das Tagged in das Management VLAN hängen. Dann in den IP Adress Settings die Bindung an das Bridge Interface entfernen und auf dieses VLAN Interface setzen.
In der Bridge dann im VLAN Setting das Interface als Tagged hinzufügen.
Das ist dein Kardinalsfehler.
Übrigens die Untagged Interfaces muss man dort im Bridge VLAN Setting nicht unbedingt eintragen. Die kannst du weglassen, es reicht wenn diese mit ihrer PVID entsprechend richtig gesetzt sind in der Bridge. Es macht die Konfig etwas übersichtlicher.
Schadet aber auch nicht wenn man sie dennoch einträgt.
Du hast die Management IP des hAP ac direkt an die Bridge selber gehängt. Das geht so nicht mehr in einem VLAN Setup der Bridge (VLAN Filtering aktiv) !
Du musst ein entsprechendes VLAN Interface anlegen mit der Management VLAN ID und das Tagged in das Management VLAN hängen. Dann in den IP Adress Settings die Bindung an das Bridge Interface entfernen und auf dieses VLAN Interface setzen.
In der Bridge dann im VLAN Setting das Interface als Tagged hinzufügen.
Das ist dein Kardinalsfehler.
Übrigens die Untagged Interfaces muss man dort im Bridge VLAN Setting nicht unbedingt eintragen. Die kannst du weglassen, es reicht wenn diese mit ihrer PVID entsprechend richtig gesetzt sind in der Bridge. Es macht die Konfig etwas übersichtlicher.
Schadet aber auch nicht wenn man sie dennoch einträgt.
Hatte die AddressList 192.168.20.2/24 vom bridge1 Interface auf VLAN20 gelegt, dann hat der MT aber immer ein eigene (dynamic) AddressList mit 192.168.20.2/24 auf bridge1 automatisch angelegt. Meine auf VLAN20 blieb parallel erhalten.
Daraufhin habe ich die bridge und AddressList Konfiguration nach deiner Anleitung komplett neu aufgesetzt.
Jetzt bekommen aber die Kupfer Clients an den entsprechenden Ports auch keine IP mehr. Radius ist nicht mehr Verfügbar, aber das wird vermutlich an der geänderten IP des NAS/Clients (192.168.20.1 anstatt vorher 192.168.20.2) des MTs für die pfsense sein.
Aufbau ist folgender:
FritzBox(192.168.10.1) --- pfsense(192.168.10.2) --- MT (192.168.20.1 oder vorher 20.2)
Mein DEFAULTVLAN ist bei mir halt im 20er Netz was in deiner Anleitung 1 ist.
Daraufhin habe ich die bridge und AddressList Konfiguration nach deiner Anleitung komplett neu aufgesetzt.
Jetzt bekommen aber die Kupfer Clients an den entsprechenden Ports auch keine IP mehr. Radius ist nicht mehr Verfügbar, aber das wird vermutlich an der geänderten IP des NAS/Clients (192.168.20.1 anstatt vorher 192.168.20.2) des MTs für die pfsense sein.
Aufbau ist folgender:
FritzBox(192.168.10.1) --- pfsense(192.168.10.2) --- MT (192.168.20.1 oder vorher 20.2)
Mein DEFAULTVLAN ist bei mir halt im 20er Netz was in deiner Anleitung 1 ist.
dann hat der MT aber immer ein eigene (dynamic) AddressList mit 192.168.20.2/24 auf bridge1 automatisch angelegt.
Das ist doch technisch völlig unmöglich, denn die Bridge hat dann doch keinerlei IP Interface bzw. irgenwelche IP Bindungen mehr !! WO bitte "siehst" du denn diese Bridge IP ?!Tödlicher Kardinalsfehler ist auch das du das dedizierte Routing Interface ether1 als Bridgeport bzw. Bridgemember eingerichtet hast !! Das geht natürlich so auch nicht und ist fatal, da es IP Chaos gibt. Das Tutorial weist explizit auf diesen Punkt hin:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Wenn du natürlich weitere solcher fatalen Kincken eingebaut hast ist klar das da Fehler passieren.
Wenn du natürlich weitere solcher fatalen Kincken eingebaut hast ist klar das da Fehler passieren.
Deswegen habe ich nach deiner Anleitung nochmal alles auf null gesetzt, aber ...Sorry ich fresse es einfach nicht wo mein Fehler liegt. Der MT bekommt keine IP vom DHCP der pfsense zugewiesen und keiner der am MT angeschlossenen Clients.
Der Port der pfsense an dem der MT hängt ist im 192.168.1.1 Netzwerk und hat einen DHCP Server laufen (ein "normaler" Kupferclient bekommt eine IP) und gleichzeitig ist auf dem Port das 200er VLAN
Nochmal vorab gefragt bevor wir ins Eingemachte gehen und Konfigs zur Lösung hier posten:
Wenn dem so ist dann darf der MT natürlich NICHT als Router arbeiten und KEINE VLAN IP Interfaces haben. Er ist dann lediglich ein Layer 2 Switch und reicht die VLANs nur durch. Damit gilt dann auch eine andere Konfig als die im Tutorial, denn dort arbeitet der MT als Router !!
Wenn dem so ist folgt eine Lösung für dieses Design.
- Der Mikrotik routet NICHT und arbeitet rein nur als VLAN Switch mit einzig einem Management Zugang. Dann gilt auch das Tutorial nicht für dich bei so einem Setup.
- Zentraler Router zw. den VLANs ist die pfSense. Nur diese routet und liefert DHCP in die VLANs
Wenn dem so ist dann darf der MT natürlich NICHT als Router arbeiten und KEINE VLAN IP Interfaces haben. Er ist dann lediglich ein Layer 2 Switch und reicht die VLANs nur durch. Damit gilt dann auch eine andere Konfig als die im Tutorial, denn dort arbeitet der MT als Router !!
Wenn dem so ist folgt eine Lösung für dieses Design.
Zwischen dem Internet und der pfsense hängt zwar noch eine FritzBox, aber sonst stimmen die Annahmen
OK, dann kannst du die Tutorial Konfig so nicht übernehmen, denn du betreibst dein MT ja dann als reinen Switch und nicht als Router wie im Tutorial.
Korrekte Konfig dafür folgt...
Korrekte Konfig dafür folgt...
Hier die Grundkonfig des Mikrotik erstmal OHNE CapsMan und WLAN. Nachgestellt auf einem hAP ac und im Beispiel hier, der Übersicht halber, nur mit 3 VLANs 1 (native Interface der pfSense, hier re0 (OPT1)), VLAN 10 und VLAN 20 wobei das VLAN 20 wie bei dir als Management VLAN eingerichtet ist. Der Mikrotik im Switchmode hat da seine Management IP.
Das musst du erstmal so zum fliegen bringen.
Ports zuweisen:
VLAN Tagging einstellen:
Achtung: Hiernach Haken bei VLAN Filtering in der Bridge nicht vergessen ! Und Haken bei "IGMP Snooping" setzen !!
IP Adressen und Routing konfigurieren:
Ping Check auf die pfSense VLAN 20:
Klappt !!!
Das hast du ja schon richtig erledigt wird hier aber der Vollständigkeit halber nochmal aufgeführt.
Hier im Test arbeitet der Uplink auf den Mikrotik auf dem "OPT1" Port der physisch dem re0 auf einem APU Bord zugeordnet ist.
Konfig des hAP ac:
Das musst du erstmal so zum fliegen bringen.
Grundeinrichtung der Mikrotik VLAN Bridge mit Management IP:
Ports zuweisen:IP Adressen und Routing konfigurieren:
pfSense Uplink Port Konfig zum Mikrotik:
Das hast du ja schon richtig erledigt wird hier aber der Vollständigkeit halber nochmal aufgeführt.Hier im Test arbeitet der Uplink auf den Mikrotik auf dem "OPT1" Port der physisch dem re0 auf einem APU Bord zugeordnet ist.
Konfig des hAP ac:
# serial number = 6CBA01234567
/interface bridge
add comment="VLAN Bridge" igmp-snooping=yes name="vlan_ bridge" vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] comment="Tagged Uplink pfSense"
set [ find default-name=ether5 ] comment="VLAN1 Port"
/interface wireless
set [ find default-name=wlan1 ] ssid=MikroTik
set [ find default-name=wlan2 ] ssid=MikroTik
/interface vlan
add comment="Management IP" interface="vlan_ bridge" name=vlan20 vlan-id=20
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/interface bridge port
add bridge="vlan_ bridge" comment="Tagged Uplink pfSense" interface=ether1
add bridge="vlan_ bridge" comment="Management Port" frame-types=admit-only-vlan-tagged interface=vlan20 pvid=20
add bridge="vlan_ bridge" frame-types=admit-only-untagged-and-priority-tagged interface=ether5
/interface bridge vlan
add bridge="vlan_ bridge" tagged="vlan_ bridge,ether1" vlan-ids=10
add bridge="vlan_ bridge" tagged="vlan_ bridge,ether1,vlan20" vlan-ids=20
/ip address
add address=172.16.20.2/24 interface=vlan20 network=172.16.20.0
/ip route
add distance=1 gateway=172.16.20.1
/system clock
set time-zone-name=Europe/Berlin
/system identity
set name=Mikrotik-hAP
/system ntp client
set enabled=yes primary-ntp=131.188.3.221
[admin@Mikrotik-hAP] > 
1
Zitat von @aqui:
Nochmal vorab gefragt bevor wir ins Eingemachte gehen und Konfigs zur Lösung hier posten:
Hallo,Nochmal vorab gefragt bevor wir ins Eingemachte gehen und Konfigs zur Lösung hier posten:
- Der Mikrotik routet NICHT und arbeitet rein nur als VLAN Switch mit einzig einem Management Zugang. Dann gilt auch das Tutorial nicht für dich bei so einem Setup.
- Zentraler Router zw. den VLANs ist die pfSense. Nur diese routet und liefert DHCP in die VLANs
hierzu hätte ich auch mal eine Frage. Ich habe bisher für mein Haus-Netz eine Lösung über mehrere Standard-Router mit DD-WRT. Da das eine ziemliche Bastelei (gewesen) ist und ich relativ günstig an einen Mikrotik-Router gekommen bin, will ich demnächst mein Netz umstellen.
So ungefähr war mir der Aufbau klar, bis ich hier darauf gestoßen bin, daß ich den Radius Server des Mikrotik nicht nutzen kann.
Jetzt überlege ich mir gerade, ob ich eine Terra Black Dwarf G3 UTM Edition bei ebay besorge um darauf pfsense zu installieren (das sollte gehen, soweit ich das verstanden habe) um als Radius Server zu dienen. Das allein ist vermutlich keine 250€ wert und ein R-Pi könnte die Aufgabe genausogut übernehmen.
Hätte ich sonst noch Vorteile bei dieser Lösung?
Wie würde ich die pfsense denn in mein Netz integrieren? Als vorgeschaltete Firewall?
Ich habe als Hardware bzw. würde ich mir noch kaufen (eingeklammert)
- Cisco SLM2024T-EU 200 Series SG200-26, 24-Port, smart managed (ist schon im Keller - dort ist das Patchfeld)
- Mikrotik CCR1009-7G-1C-1S+ der als Router dienen soll (im Keller)
(*) Mikrotik cAP im Keller (WLAN-AP im Keller)
(*) Mikrotik cAP in der 1.Etage (WLAN-AP Etage 1)
Mein Aufbau wie ich ihn mir vorgestellt hatte
+-- DMZ
|
I-Net---Fritzbox+-- CCR1009 -- Cisco Switch -- Patchfeld
| | |
| | +-- cAP
| |
| +-- cAP
|
+ -- RB4011- VLAN für meine Kinder - abgeschottet von meinem VLAN
- VLAN für mich und meine Frau
- WLAN in obigen VLANs (dynamisch nach Tutorial)
- VLAN für Drucker und vielleicht auch für die NAS mit Zugriff aus den beiden anderen VLANs
- DMZ für Wii Console und Festplattenreceiver
- Gäste WLAN
Welche Dienste sollte sie übernehmen?
- Radius Server - OK, aber lohnt sich das?
- Firewall - sinnvoll? kann ja auch der MT
- DHCP-Server - sinnvoll? kann ja auch der MT
daß ich den Radius Server des Mikrotik nicht nutzen kann.
So pauschal kann man das nicht sagen und so wäre diese Aussage auch falsch.Man kann ihn schon nutzen für alle User basierten Authentisierungen usw. aber leider nicht für dynamische VLANs, weil (so paradox es klingt) er die nur dafür erforderlichen Vendor spezifischen Attribute nicht supportet.
Ansonsten kann der Radius das alles schon.
Hätte ich sonst noch Vorteile bei dieser Lösung?
Ja, du hättest Firewall Internet Router und Radius alles in einer Box. Platz und Resourcen sparend.Wie würde ich die pfsense denn in mein Netz integrieren? Als vorgeschaltete Firewall?
Ein Bild sagt mehr als 1000 Worte... Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Dort hast du genügend Einsatz Szenarien.
pfSense als Internet Router und MT dahinter im Switch oder Router Mode.
Bringt die pfsense hier zusätzliche Vorteile?
Zusätzlich sicher keine. Wenn für dich als Radius auch ein vorhandenes NAS oder ein RasPi in Frage kommt dann könntest du auch alles rein mit dem MT machen dann entfällt der Knackpunkt Radius auf der FW ja komplett und damit das Argument für die FW.In so fern bringt die FW dann nicht wirklich mehr.
Hallo und vielen Dank schon mal für die Antwort
Den Mikrotik als Switch zu betreiben wäre reine Verschwendung meiner Meinung nach
https://mikrotik.com/product/CCR1009-7G-1C-1Splus#fndtn-testresults
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Dort hast du genügend Einsatz Szenarien.
pfSense als Internet Router und MT dahinter im Switch oder Router Mode.
Genau das ist ja mein Problem pfSense als Router und den MT dahinter im Switch Mode sehe ich nicht als sinnvoll an in meinem Fall.
Den Fall pfSense als Internet Router und MT im Router Mode musst du mir erklären, den sehe ich dort in keinem Szenario.
Was soll der MT dahinter noch routen?
Ich sehe eigentlich immer nur einen Router ODER pfSense. Deinen von mir vorhin zitierten Post habe ich aber dann so interpretiert, als hättest du erst ein anderes Szenario im Kopf gehabt mit pfSense als ??? und MT der das Routing übernimmt und bist erst mit diesem Post darauf gekommen dass die pfSense hier auch das Routing übernimmt. Dieses Szenario ist mir aber völlig unklar.
In so fern bringt die FW dann nicht wirklich mehr.
Die pfsense Lösung klingt für mich erst mal besser als wieder eine Bastellösung mit R-Pi. Allerdings klingt die pfsense Lösung nur für einen Radius Server für mich auch wieder irre.
Deswegen meine Frage nach einem anderen Szenario
Zitat von @aqui:
ich habe aber den Mikrotik Router schon, die pfsense-Hardware müsste ich mir noch kaufen. Nicht das ich das nicht machen würde, wenn es etwas bringt.Hätte ich sonst noch Vorteile bei dieser Lösung?
Ja, du hättest Firewall Internet Router und Radius alles in einer Box. Platz und Resourcen sparend.Den Mikrotik als Switch zu betreiben wäre reine Verschwendung meiner Meinung nach
https://mikrotik.com/product/CCR1009-7G-1C-1Splus#fndtn-testresults
Wie würde ich die pfsense denn in mein Netz integrieren? Als vorgeschaltete Firewall?
Ein Bild sagt mehr als 1000 Worte... Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Dort hast du genügend Einsatz Szenarien.
pfSense als Internet Router und MT dahinter im Switch oder Router Mode.
Den Fall pfSense als Internet Router und MT im Router Mode musst du mir erklären, den sehe ich dort in keinem Szenario.
Was soll der MT dahinter noch routen?
Ich sehe eigentlich immer nur einen Router ODER pfSense. Deinen von mir vorhin zitierten Post habe ich aber dann so interpretiert, als hättest du erst ein anderes Szenario im Kopf gehabt mit pfSense als ??? und MT der das Routing übernimmt und bist erst mit diesem Post darauf gekommen dass die pfSense hier auch das Routing übernimmt. Dieses Szenario ist mir aber völlig unklar.
Bringt die pfsense hier zusätzliche Vorteile?
Zusätzlich sicher keine. Wenn für dich als Radius auch ein vorhandenes NAS oder ein RasPi in Frage kommt dann könntest du auch alles rein mit dem MT machen dann entfällt der Knackpunkt Radius auf der FW ja komplett und damit das Argument für die FW.In so fern bringt die FW dann nicht wirklich mehr.
Deswegen meine Frage nach einem anderen Szenario
- als die pfsense nur als Radius Server zu nutzen
- die pfsense als Router einzusetzen wenn der MT das besser kann
Allerdings klingt die pfsense Lösung nur für einen Radius Server für mich auch wieder irre.
Das ist absolut richtig und macht natürlich keinen Sinn.Wie gesagt, wenn du den Radius anders unterbringen kannst, RasPi, NAS usw. ist der reinen Mikrotik Weg natürlich der sinnvollere, keine Frage !
So, nun ist Kollege @Phil100Vol mal wieder dran mit hoffentlich dem Feedback das alles rennt und wir enspannt ins Wochenende können...?!
Hi , so jetzt konnte ich mal wieder testen und deine Konfi übernehmen ... es funktioniert teilweise...
Mit Radius und dyn. VLan bin ich noch nicht soweit
- Der Mikrotik bekommt immer noch keine IP zugewiesen. Ich sehe ihn nicht als DHCP Teilnehmer in der pfsense und im Startmenu der WinBox wird er mit 0.0.0.0 angezeigt ---- eigentlich sollte er doch aus dem VLAN20 eine IP bekommen oder ?
- Der Cu-Client auf Port 5 bekommt eine IP aus dem VLAN 1 ... 192.168.1.X --- CHECK
- Der Cu-Client auf Port 3 bekommt eine IP aus aus dem VLAN 222 ... 192.168.222.X --- CHECK
Mit Radius und dyn. VLan bin ich noch nicht soweit
Der Mikrotik bekommt immer noch keine IP zugewiesen. I
Dann hast du einen groben Fehler in der Zuweisung der VLANs oder der PVID auf dem Tagged Uplink gemacht der MT als Switch und die pfSense verbindet ! Das ist sicher.Checke also bitte noch einmal deine Konfig das es wirklich so eingestellt ist wie die Screenshots es oben zeigen ! Das Design funktionierte hier im Testaufbau auf ALLEN Mikrotik Modellen CRS305, hAP, RB750 und einem RB2011 vollkommen problemlos !! Es zeigt also sicher das du einen Konfig Fehler irgendwo gemacht hast !
Der Cu-Client auf Port 5 bekommt....
Was ist damit jetzt genau gemeint ??? Ist OK und funktioniert wie es soll ?!?Mit Radius und dyn. VLan bin ich noch nicht soweit
Das ist auch genau richtig so !!!Du solltest zuallererst dieses simple Grunddesign zum laufen bringen. Das ist die Basis von allem ! Ansonsten macht es sehr wenig Sinn mit einem nicht funktionierenden Grunddesign weiterzumachen.
Im Zweifel poste hier bitte nochmal dein aktuelles Setup, dann machen wir uns hier auf die Fehlersuche wo du was verbockt hast !
Hilfreich wäre nochmal eine kurze aktuelle Liste erstens der pfSense:
- Welches ist das Parent Interface (Untagged) was den Uplink realisiert und welche IP hat es und in welchem VLAN des Mikrotik soll das liegen (PVID) ?
- ...und zweitesn des MT. Welcher Port ist dein Mikrotik Uplink. Ggf. Screenshots der Konfig
Ja den Bock muss ich noch finden 
VLAN PVID entspricht Netzbereich des DHCP 192.168.XXX.1
MT ether1 hängt auf pfsense igb2 (Netzbereich 192.168.1.1) wo auch die beiden VLANs 20 und 99 getagged sind.
DHCP Server auf pfsense ist für alle 4 Lans aktiviert.
VLAN PVID entspricht Netzbereich des DHCP 192.168.XXX.1
MT ether1 hängt auf pfsense igb2 (Netzbereich 192.168.1.1) wo auch die beiden VLANs 20 und 99 getagged sind.
Der Cu-Client auf Port 5 bekommt....
Soll heißen, dass ein Kupfer Client auf dem Port eine IP zugewiesen bekommt und von der pfsense als DHCP Lease gelistet istMT ether1 hängt auf pfsense igb2 (Netzbereich 192.168.1.1) wo auch die beiden VLANs 20 und 99 getagged sind.
Etwas verwirrend ist hier der Port "5_LAN" ?! Das ist aber kein VLAN sondern ein eigenständiges und separates Segment, richtig ? Es liegt ja physisch auf einem komplett anderen Interface und ist somit völlig außen vor was die VLAN Struktur auf dem MT anbetrifft. Aber das ist vermutlich sicher auch so gewollt.Gut, gehen wir also von igb2 aus, dann ist:
- 1_LAN = Ungetaggt und Default VLAN. Hier zählt die PVID an ether1 !
- VLAN 20 und 99 dann getagged.
- Du hast Für die 3 VLANs fälschlicherweise VLAN Interfaces erzeugt ! Das ist FALSCH und wurde oben auch mehrfach drauf hingewiesen !! Diese Interfaces brauchst du einzig nur wenn du routen willst auf dem Mikrotik was bei dir aber NICHT der Fall ist, da das ja die pfSense macht !! Den Mikrotik arbeitet rein nur als simpler Layer 2 Switch mit einer einzigen Management IP.
- Lösche also bitte ALLE VLAN Interfaces bis auf das wo sich dein Management VLAN befindet. Nach deinen Angaben ist das ja das VLAN 20, richtig ? Folglich gibt es also dann rein nur das VLAN 20 Interface aber sonst KEINE anderen VLAN Interfaces in den Interface Settings !
So muss das bei dir aussehen:
VLAN 20 Interface anlegen und NUR VLAN 20 !:
Jetzt bist du wieder dran und das dann hoffentlich mit richtiger und final funktionierender Grundkonfig ?!
Sorry habe das mit den VLANs auf dem MT immer nicht so wahr genommen - hatte deine Routinganleitung immer im Hinterkopf...
Habs jetzt so übernommen und der MT bekommt in der Winbox die o.g. IP zugewiesen. In der pfsense sehe ich den MT aber weiterhin nicht als Lease. Auch kann ich mich über Winbox nicht über die IP auf den MT schalten, sondern nur über die MAC
Habs jetzt so übernommen und der MT bekommt in der Winbox die o.g. IP zugewiesen. In der pfsense sehe ich den MT aber weiterhin nicht als Lease. Auch kann ich mich über Winbox nicht über die IP auf den MT schalten, sondern nur über die MAC
Auch kann ich mich über Winbox nicht über die IP auf den MT schalten, sondern nur über die MAC
Dann bist du mit deinem WinBox Rechner irgendwo in einem anderen VLAN und dein Routing ist noch fehlerhaft oder du hast falsche oder fehlerhafte Firewall Regelwerke zw. den 3 VLAN Segmenten !Hier solltest du für die Testphase erstmal "any to any" Schrotschussregeln definieren !
Wenn du den MT dynamisch eine IP via DHCP Client ziehen lässt, dann kannst du ja auch im Routing (IP -> Routes) checken ob er auch eine dynmaische Default Route bekommt.
Ich checke das hier mal auf der pfSense mit der Lease Anzeige in der pfSense.
Deinen Zeilen oben entnehmen wir dann nun das die Grundkonfig scheinbar fehlerlos rennt, ist das richtig ?
Über das Mikrotik Ping Tool solltest du dann alle 3 VLAN Interfaces der pfSense pingen können, entsprechende FW Regeln vorausgesetzt.
Analog auch andersrum über das Ping Tool im Diagnostics Menü der pfSense indem du dort auch die Absender IP anpasst zum Quercheck.
Dann bist du mit deinem WinBox Rechner irgendwo in einem anderen VLAN und dein Routing ist noch fehlerhaft oder du hast falsche oder fehlerhafte Firewall Regelwerke zw. den 3 VLAN Segmenten !
Jope das wars - kann mich auch über die IP nun einloggen.Deinen Zeilen oben entnehmen wir dann nun das die Grundkonfig scheinbar fehlerlos rennt, ist das richtig ?
Von der pfsense kann ich aus dem VLAN20 alle Interfaces anpingen (1 , 5 & 99)
Von dem MT kann ich nur das 20er VLAN und deren Clients im 20er Bereich anpingen. VLAN 5 und 99 bringen timeout
keine verdächtigen Einträge in den pfsense Firewall logs
Jope das wars - kann mich auch über die IP nun einloggen.
Wollt ich grad sagen....!! Die Erklärung dafür ist auch ganz logisch. Das passiert wenn du im VLAN 1 des Parent Interfaces mit deinem Client sitzt ! Das sind alle Ports des hAP die weiterhin mit der PVID 1 gesetzt sind !
Du bekommst dann eine IP aus dem Parent Interface VLAN (idg2) bei dir 192.168.1.x, bist aber für das Management des MT im falschen VLAN. Logisch, denn er hat ja keine IP in dem Netz.
Die Layer 2 Hello Pakete für die WinBox Autodetection kommen vom MT untagged vom physischen Interface ether1 deshalb siehst du diese, aber eben nur die L2 Frames ohne die IP, deshalb wird dir im WinBox Neigbor Fenster "0.0.0.0" angezeigt und die Connection geht nur über die Mac.
Alles ganz normal also...
Wenn du also einen Port das hAP ins Management VLAN legen willst (Hier Beispiel ether5) dann musst du dort einfach nur die richtige PVID setzen (20). Damit ist der Port dann im VLAN 20 und dein WinBox PC bekommt dann auch eine IP aus dem Mamagement und nicht Parent VLAN. Er empfängt die WinBox Hellos mit IP und zeigt diese dann auch richtig an weil die IP Zuordnung nun wieder stimmt.
Allso alles ganz normal....works as designed !
Von dem MT kann ich nur das 20er VLAN und deren Clients im 20er Bereich anpingen. VLAN 5 und 99 bringen timeout
Das zeigt das du...- entweder die Default Route vergessen hast einzutragen auf dem MT. Oder, falls DHCP das...
- du falsche oder fehlerhafte Firewall Regeln auf den Interfaces 1, 5 und/oder 99 eingerichtet hast die ICMP aus dem 20er VLAN oder das 20 VLAN selber blocken ! Die verdächtigen Einträge gäbe es in dem Falle dann im Firewall Log der pfSense !
Wenn du also einen Port das hAP ins Management VLAN legen willst (Hier Beispiel ether5) dann musst du dort einfach nur die richtige PVID setzen (20).
IP aus der IP->Addresses wird angezeigt
In der Lease Übersicht taucht aber nur der WinBox Client auf, nicht der MT
In der Lease Übersicht taucht aber nur der WinBox Client auf, nicht der MT
Nur mal doof nachgefragt: Hast du dem MT eine statische IP gegeben ? Wenn ja ist es logisch das der da dann nicht auftaucht, da statisch.Soll er sich aber eine Management IP per DHCP von der pfSense ziehen, dann müsst du logischerweise die statische IP unter IP --> Address und auch die statische Route unter IP --> Routes komplett löschen und den Mikrotik dann als DHCP Client unter IP --> DHCP Client auf dem VLAN Interface 20 setzen.
Nur dann zieht er sich automatisch eine IP und taucht dann logischerweise auch im pfSense DHCP Server unter Leases auf:
Habe die IP Address und IP Routes gelöscht und den MT als DHCP Client im VLAN 20 angesetzt. Jetzt zieht er eich eine IP aus dem Pool
MAC ...:72
wenn ich jetzt versuche über die pfsense dem Lease eine statische IP ausserhalb des Pools zu vergeben (aber immer noch im 20er Netz)
funktioniert es bis zu einem Neustart des MTs.
Dann bezieht er wieder eine neue IP aus dem DHCP Pool weil auch eine neue MAC verwendet wird
MAC ...:00
wenn ich jetzt versuche über die pfsense dem Lease eine statische IP ausserhalb des Pools zu vergeben (aber immer noch im 20er Netz)
funktioniert es bis zu einem Neustart des MTs.
Dann bezieht er wieder eine neue IP aus dem DHCP Pool weil auch eine neue MAC verwendet wird
MAC ...:00
Ja, das ist bekannt bei Mikrotik in den Bridge Interfaces ! Lösung ist kinderleicht...
Du musst die VLAN 20 Interface Mac auf Static setzen.
https://vswitchzero.com/2019/08/23/preventing-mikrotik-routeros-bridge-m ...
Geht auch über die WinBox.
Du musst die VLAN 20 Interface Mac auf Static setzen.
https://vswitchzero.com/2019/08/23/preventing-mikrotik-routeros-bridge-m ...
Geht auch über die WinBox.
works like a charm
auto-mac habe ich in WinBox Gui nicht gefunden , nur übers Terminal
Du musst die VLAN 20 Interface Mac auf Static setzen.
Habe halt die bridge auf eine feste MAC und Auto-mac=no gesetzt (nach deinem Link - mit angepassten Werten)/interface bridge set bridge1 admin-mac=4e:a4:50:f4:e7:1C auto-mac=noauto-mac habe ich in WinBox Gui nicht gefunden , nur übers Terminal
Habe mittlerweile deine Konfi bezüglich dem Radius und Capsman übernommen und der Wlan Client1 wird vom Radius akzeptiert:
der Client mit MAC taucht auch im CAPsMAN - RegistrationTable auf, aber bekommt nur die ZeroConf IP
DHCPOffer von der pfsense kommt, aber Client "erhält" diese nicht
Wie du schon am 31.05 bemerkt hast:
Das MAC Format im MT ist auf XX:XX ... gesetzt, dennoch wird in den Logs immer mal die MAC groß geschrieben, dann mal wieder klein, mal mit ":" und mal mit "-" als Trennzeichen (z.B.: Login OK: [AA:BB:CC:DD:EE:FF] (from client MT_hAPac2 port 0 cli aa-bb-cc-dd-ee-ff)).
Macht das was?
(0) Login OK: [AA:BB:CC:DD:EE:FF] (from client MT_hAPac2 port 0 cli aa-bb-cc-dd-ee-ff)
(0) Sent Access-Accept Id 20 from 192.168.20.1:1812 to 192.168.20.2:49987 length 0
(0) Tunnel-Type = VLAN
(0) Tunnel-Medium-Type = IEEE-802
(0) Mikrotik-Wireless-VLANID = 99
(0) Mikrotik-Wireless-Comment = "Client1"
(0) Finished request
Waking up in 4.9 seconds.
(0) Cleaning up request packet ID 20 with timestamp +3der Client mit MAC taucht auch im CAPsMAN - RegistrationTable auf, aber bekommt nur die ZeroConf IP
DHCPOffer von der pfsense kommt, aber Client "erhält" diese nicht
Jun 7 21:57:16 dhcpd DHCPOFFER on 192.168.99.100 to aa:bb:cc:dd:ee:ff (Client1) via igb2.99
Jun 7 21:57:16 dhcpd DHCPDISCOVER from aa:bb:cc:dd:ee:ff (Client1) via igb2.99 Wie du schon am 31.05 bemerkt hast:
Vermutlich irgendwo ein Tagging Fehler.
Das MAC Format im MT ist auf XX:XX ... gesetzt, dennoch wird in den Logs immer mal die MAC groß geschrieben, dann mal wieder klein, mal mit ":" und mal mit "-" als Trennzeichen (z.B.: Login OK: [AA:BB:CC:DD:EE:FF] (from client MT_hAPac2 port 0 cli aa-bb-cc-dd-ee-ff)).
Macht das was?
Nur zur Info. Kollege @colinardo hat ein Tutorial veröffentlich was die kommende (derzeit Beta) Implementation des Radius auf dem MT selber beschreibt:
Mikrotik: 802.1X Port basierte Authentifizierung mit Zertifikaten unter RouterOS 7 mit User-Manager als Radius-Server
Sieht so aus als ob Mikrotik ihren abgespeckten Radius nun richtig aufbohren...
Weiter im Thread hier...
Du kannst das doch sehr einfach und schnell einmal direkt am hAP ac vorab wasserdicht testen...
Setze einen Kupfer Port am hAP mal auf die PVID 99 und schliesse einen Test Laptop da an. Der sollte sofort eine IP aus dem VLAN 99 von der pfSense bekommen.
Wenn nicht dann stimmen eins oder mehrere der o.g. 3 Punkte nicht.
So kommt der Request rein was du ja am Radius sehen kannst: Wichtig ist nur was hier unter User-Name und User-Password steht. So kommt es vom Access Point am Radius rein. Dort kannst du auch sehen das das Format XX: stimmt zu dem was konfiguriert und das es Großschrift ist. Dieses Format ist das was zählt und was mit der User Datenbnak bzw. Konfig verglichen wird !
Mikrotik: 802.1X Port basierte Authentifizierung mit Zertifikaten unter RouterOS 7 mit User-Manager als Radius-Server
Sieht so aus als ob Mikrotik ihren abgespeckten Radius nun richtig aufbohren...
Weiter im Thread hier...
der Client mit MAC taucht auch im CAPsMAN - RegistrationTable auf, aber bekommt nur die ZeroConf IP
Das zeigt eindeutig das die zugewiesene VLAN ID 99 keine Verbindung auf den DHCP Server der Firewall bekommen hat. Dazu kann es mehrere Gründe geben:- Du hast die VLAN 99 Zuordnung in der Bridge nicht oder fehlerhaft gemacht (Screenshot !)
- DHCP Server auf VLAN 99 in der Firewall ist nicht aktiv
- Tag Interface VLAN 99 an der Firewall fehlt.
Du kannst das doch sehr einfach und schnell einmal direkt am hAP ac vorab wasserdicht testen...
Setze einen Kupfer Port am hAP mal auf die PVID 99 und schliesse einen Test Laptop da an. Der sollte sofort eine IP aus dem VLAN 99 von der pfSense bekommen.
Wenn nicht dann stimmen eins oder mehrere der o.g. 3 Punkte nicht.
Das MAC Format im MT ist auf XX:XX ... gesetzt, dennoch wird in den Logs
Was in den Logs steht ist Schall und Rauch. Wichtig ist was der Radius sagt !! Wenn der ein "Sent Access-Accept" ausführt, dann ist für ihn alles OK und der Client authentisiert.So kommt der Request rein was du ja am Radius sehen kannst:
Ready to process requests
(0) Received Access-Request Id 10 from 192.168.88.1:38133 to 192.168.88.222:1812 length 145
(0) Service-Type = Framed-User
(0) NAS-Port-Id = "cAP Rechts"
(0) NAS-Port-Type = Wireless-802.11
(0) User-Name = "0022:FA7B:C9A6"
(0) User-Password = "0022:FA7B:C9A6"
(0) Acct-Session-Id = "82700000"
(0) Calling-Station-Id = "00-22-FA-7B-C9-A6"
(0) Called-Station-Id = "64-D1-54-F6-39-C2"
(0) NAS-Identifier = "hAP-Test"
(0) NAS-IP-Address = 192.168.88.1 Du hast die VLAN 99 Zuordnung in der Bridge nicht oder fehlerhaft gemacht (Screenshot !)
--> siehe untenDHCP Server auf VLAN 99 in der Firewall ist nicht aktiv
--> Ist aktiviert und funktioniert mit einem Kupfer Client an einem PortTag Interface VLAN 99 an der Firewall fehlt.
--> Ist gesetzt sonst würde ja der zweite Anstrich nicht funktionierenLösche also bitte ALLE VLAN Interfaces bis auf das wo sich dein Management VLAN befindet. Nach deinen Angaben ist das ja das VLAN 20, richtig ? Folglich gibt es also dann rein nur das VLAN 20 Interface aber sonst KEINE anderen VLAN Interfaces in den Interface Settings !
Also gilt deine Aussage dann nicht mehr, weil ich der Bridge kein VLAN99 zuordnen kann, weil ich bisher keines erstellt hatte
Setze einen Kupfer Port am hAP mal auf die PVID 99 und schliesse einen Test Laptop da an. Der sollte sofort eine IP aus dem VLAN 99 von der pfSense bekommen
--> FunktioniertDie aktuelle Bridge Konfi:
Also gilt deine Aussage dann nicht mehr, weil ich der Bridge kein VLAN99 zuordnen kann, weil ich bisher keines erstellt hatte
Um das VLAN 99 in der Bridge zu definieren brauchst du KEIN VLAN 99 IP Interface ! Du willst ja nicht routen. In sofern bleibt es dabei. Das VLAN 99 kannst du natürlich in der Bridge VLAN Definition immer auch ohne existierendes IP Interface eintragen. Wichtig ist nur das das VLAN als solches dafür definiert ist.
So wie oben ist es richtig !
Kannst du ja auch daran sehen das es mit dem Kupfer Port sauber und fehlerlos klappt. Mit der VLAN Bridge hat es also nichts zu tun. Es kann nur noch an der Anbindung der WLAN Interfaces an die Bridge liegen. Da ist also noch irgendwas im Argen.
Nebenbei musst du den Kupferport da nicht Untagged eintragen. Das kannst du weglassen. Es reicht wenn man den in der Interface Zuordnung nur mit der PVID setzt. Ist aber hier ncht das Thema und nur kosmetisch.
Da das VLAN Setup in der Bridge OK ist kann es dann nur noch am Datapath Setup des CapsMan liegen das da ein Fehler ist. Was etwas komisch ist, ist nämlcih das da "wlan3" als Tagged auftaucht obwohl es in der Bridge nicht definiert. Ist. Das zeigt das da irgendwo noch ein Kinken ist in der Konfig.
Was etwas komisch ist, ist nämlcih das da "wlan3" als Tagged auftaucht obwohl es in der Bridge nicht definiert. Ist. Das zeigt das da irgendwo noch ein Kinken ist in der Konfig.
wlan3 ist ein virtuelles Wlan von wlan1. Wlan3 ist das GastWlan in VLAN99 Bereich (separate SSID) welche nur ins 99 Netz gehen soll. Wlan1 soll das dynamische WLan sein (also dyn. VLAN Zuweisung). Hier hatte ich jetzt probeweise dem Client1 im Radius die VLANID 99 zugewiesen - später auch andere VLANs je nach MAC
Du musst hier aber aufpassen. Du benutzt ja dann eine gemischte Umgebung wo du einmal einen AP hast mit dynamischer Zuweisung und einmal deinen statischen wo du dann statisch zuweist. Wenn man dich jetzt nach der obigen Beschreibung richtig versteht ?!
Du kannst aber nicht die VLAN IDs dann zwischen diesen Verfahren mixen. Dieser virtuelle AP müsste dann mit statischer VLAN Zuodnung definiert sein und OHNE Radius.
Der Sinn ist auch vollkommen unverständlich. Du brauchst das doch gar nicht, denn deine Gäste filtern sich ja von ganz allein über das Default Setting. Alle die nicht erfasst sind in deinem Radius stuft er als unauthorisierte Gäste ein und schmeisst sie dann dynamisch ins VLAN 99 Gummizellen VLAN wo sie das Captive Portal sehen. Da musst du doch gar nichts statisch zuweisen ??
Du kannst aber nicht die VLAN IDs dann zwischen diesen Verfahren mixen. Dieser virtuelle AP müsste dann mit statischer VLAN Zuodnung definiert sein und OHNE Radius.
Der Sinn ist auch vollkommen unverständlich. Du brauchst das doch gar nicht, denn deine Gäste filtern sich ja von ganz allein über das Default Setting. Alle die nicht erfasst sind in deinem Radius stuft er als unauthorisierte Gäste ein und schmeisst sie dann dynamisch ins VLAN 99 Gummizellen VLAN wo sie das Captive Portal sehen. Da musst du doch gar nichts statisch zuweisen ??
Wenn man dich jetzt nach der obigen Beschreibung richtig versteht ?!
Richtig verstanden.Dieser virtuelle AP müsste dann mit statischer VLAN Zuodnung definiert sein und OHNE Radius.
Ja nur der "Dyn AP" soll über den Radius laufen und der "Statische" nicht. Daher habe ich auch nur für das dyn. Cap Interface eine AccessRule gesetzt und bei dem anderen nix
Der Sinn ist auch vollkommen unverständlich.
Mein Sinn war die "Bequemlichkeit" = Erleichterung für die Gäste. Das dyn. Wlan hat eine wesentlich längere passphrase (aus Sicherheitsbedenken) und die passphrase für das GästeWlan kurz und einfach
Das müsste ich jetzt mit einem separaten virtuellen AP auch mal nachstellen...
Leider werden den WLAN Clients immer noch nur die IPs per DHCP angeboten aber letztendlich nur die Zero Conf Ip vom Client übernommen (in dyn. WLAN). Verbindung von Client zu MT steht laut Registration Table
Hier ist ein Minimal Test Setup im Switch Mode auf einem hAP ac mit den VLANs 1, 10 und 20 (Management) und beiden 2,4Ghz und 5Ghz APs und erstmal ohne CapsMan mit dem die dynamische VLAN Zuordnung fehlerlos klappt.
Diese Konfig baut auf dem o.a. Grundsetup auf und sollte erstmal dein nächster strategischer Schritt sein den du zum Fliegen bringen solltest !!
Diese Konfig baut auf dem o.a. Grundsetup auf und sollte erstmal dein nächster strategischer Schritt sein den du zum Fliegen bringen solltest !!
Bridge Ports:
Bridge VLANs:
WLAN Interfaces:
Konfiguration:
# # jun/11/2020 12:00:22 by RouterOS 6.47
#
# model = RouterBOARD hAP ac
# serial number = 6CBA01234567
/interface bridge
add comment="VLAN Bridge" igmp-snooping=yes name="vlan_ bridge" vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] comment="Tagged Uplink pfSense"
set [ find default-name=ether5 ] comment="VLAN1 Port"
/interface vlan
add comment="Management IP" interface="vlan_ bridge" name=vlan20 vlan-id=20
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa2-psk eap-methods="" management-protection=allowed mode=\
dynamic-keys name=Radius radius-called-format=mac radius-mac-authentication=yes \
radius-mac-format=XXXX:XXXX:XXXX radius-mac-mode=as-username-and-password \
supplicant-identity="" wpa2-pre-shared-key=test1234
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-g/n country=germany disabled=no frequency=2422 \
mode=ap-bridge multicast-helper=full name=AP-2.4Ghz security-profile=Radius ssid=\
hAP-Radius wireless-protocol=802.11 wmm-support=enabled wps-mode=disabled
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=20/40mhz-eC country=germany \
disabled=no frequency=auto mode=ap-bridge multicast-helper=full name=AP-5Ghz \
security-profile=Radius ssid=5Ghz-Radius wireless-protocol=802.11 wmm-support=enabled \
wps-mode=disabled
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/interface bridge port
add bridge="vlan_ bridge" comment="Tagged Uplink pfSense" interface=ether1
add bridge="vlan_ bridge" comment="Management IP Interface" frame-types=\
admit-only-vlan-tagged interface=vlan20 pvid=20
add bridge="vlan_ bridge" comment="Management Port" frame-types=\
admit-only-untagged-and-priority-tagged interface=ether5 pvid=20
add bridge="vlan_ bridge" comment="Management Port" frame-types=\
admit-only-untagged-and-priority-tagged interface=ether4 pvid=20
add bridge="vlan_ bridge" comment="Testport VLAN10" frame-types=\
admit-only-untagged-and-priority-tagged interface=ether3 pvid=10
add bridge="vlan_ bridge" comment="AP 2.4 Ghz" interface=AP-2.4Ghz
add bridge="vlan_ bridge" interface=AP-5Ghz
/interface bridge vlan
add bridge="vlan_ bridge" comment=Bridge-VLAN10 tagged=\
"vlan_ bridge,ether1,AP-2.4Ghz,AP-5Ghz" vlan-ids=10
add bridge="vlan_ bridge" comment=Bridge-VLAN20 tagged=\
"vlan_ bridge,ether1,vlan20,AP-2.4Ghz,AP-5Ghz" vlan-ids=20
/ip dhcp-client
add disabled=no interface=vlan20
/ip route
add distance=1 gateway=172.16.20.1
/radius
add address=172.16.20.1 comment="WLAN Radius Server" secret=testing123 service=wireless
/system clock
set time-zone-name=Europe/Berlin
/system identity
set name=Mikrotik-hAP
/system ntp client
set enabled=yes primary-ntp=131.188.3.221
Hi,
so jetzt konnte ich wieder weiter werkeln ... nachdem ich nach deiner letzten Konfi das blanke (ohne CAPsMAN) Wlan Interface mit dyn. Vlan - Zuweisung einrichten konnte, habe ich das ganze mit CAPsMAN versucht. Siehe da - es fliegt ...
Mein Fehler war wohl, dass ich die cap_interface der bridge-ports und bridge-vlans zugewiesen habe, anstatt den wlan_interaces (in der Anleitung z.B. "AP-2.4GHz")
Von meiner Seite ist der Case gelöst
Vielen Dank für die Hilfe und ausführliche Beratung ...! Wie immer topp
so jetzt konnte ich wieder weiter werkeln ... nachdem ich nach deiner letzten Konfi das blanke (ohne CAPsMAN) Wlan Interface mit dyn. Vlan - Zuweisung einrichten konnte, habe ich das ganze mit CAPsMAN versucht. Siehe da - es fliegt ...
Mein Fehler war wohl, dass ich die cap_interface der bridge-ports und bridge-vlans zugewiesen habe, anstatt den wlan_interaces (in der Anleitung z.B. "AP-2.4GHz")
Von meiner Seite ist der Case gelöst
Vielen Dank für die Hilfe und ausführliche Beratung ...! Wie immer topp
Von meiner Seite ist der Case gelöst
👍Und danke für die Blumen !
Ich versuch seit 2Stunden den Mikrotik cAP ac (v.6.48.3) zu verstehen.
VLAN Routing soll auf der pfSense passieren.
Komm nicht weiter, außerdem erzeugt die Frau des Hauses gewaltigen Druck (Sie ist im Home Office und benötigt das WLAN, zusätzlich ist die gute auch noch hungrig!!! #gefahr)
So würde ich das ganze gerne hinbekommen:
VLAN Routing soll auf der pfSense passieren.
Komm nicht weiter, außerdem erzeugt die Frau des Hauses gewaltigen Druck (Sie ist im Home Office und benötigt das WLAN, zusätzlich ist die gute auch noch hungrig!!! #gefahr)
So würde ich das ganze gerne hinbekommen:
Guckst du hier:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
1
Habs hinbekommen danke
AAAAber ich Layer8 Problem, hab gerade etwas "probiert". Ich wollte das "WEB Gui bzw WinBox" in mein Mangement VLAN Portieren, und dachte wenn ich unter Bridge VLAN Filtering Aktiviere und dort die VLAN ID eintrage geht das....
Jetzt geht gar nichts mehr, und ich finde mit Winbox nichtmal mehr den cAP ac.
Hast du vielleicht eine idee?
AAAAber ich Layer8 Problem, hab gerade etwas "probiert". Ich wollte das "WEB Gui bzw WinBox" in mein Mangement VLAN Portieren, und dachte wenn ich unter Bridge VLAN Filtering Aktiviere und dort die VLAN ID eintrage geht das....
Jetzt geht gar nichts mehr, und ich finde mit Winbox nichtmal mehr den cAP ac.
Hast du vielleicht eine idee?
Habs hinbekommen danke
👍Hast du vielleicht eine idee?
Ja. In der Default Konfig gibt es eine "Interface List". Diese gibt es für WAN und LAN Ports und Interfaces mit Management Zugriff woe die WinBox müssen in der Liste "LAN" definiert sein, denn nur dort sind die Management Zugriffe erlaubt. In der WAN Liste oder auch ganz ohne Listendeklaration dieser Ports ist der Management Zugriff aus Sicherheit immer verboten. Also VOR dem dem Umkonfigurieren immer sicherstellen das der VLAN IP Port auch der LAN Liste zugewiesen ist. Zitat von @aqui:
Habs hinbekommen danke
👍Hast du vielleicht eine idee?
Ja. In der Default Konfig gibt es eine "Interface List". Diese gibt es für WAN und LAN Ports und Interfaces mit Management Zugriff woe die WinBox müssen in der Liste "LAN" definiert sein, denn nur dort sind die Management Zugriffe erlaubt. In der WAN Liste oder auch ganz ohne Listendeklaration dieser Ports ist der Management Zugriff aus Sicherheit immer verboten. Also VOR dem dem Umkonfigurieren immer sicherstellen das der VLAN IP Port auch der LAN Liste zugewiesen ist. Also HW Reset und neu konfigurieren?
Also HW Reset und neu konfigurieren?
Kommt drauf an... Hast du noch ein Interface was ggf. noch auf die WinBox reagiert ?? Ggf. alle durchprobieren.Man sollte sich immer ein Notfall Interface mit der Standard Konfig belassen BEVOR man umschaltet auf Filtering.
Wenn nichts mehr reagiert kommst du um einen Reset nicht drumrum.
Aber du hast ja ganz sicher die Konfig VOR dem Umschalten aufs Filtering intelligenterweise gesichert und kannst die dann ganz schnell wieder mit einem simplen Mausklick einspielen !
Zitat von @aqui:
Man sollte sich immer ein Notfall Interface mit der Standard Konfig belassen BEVOR man umschaltet auf Filtering.
Wenn nichts mehr reagiert kommst du um einen Reset nicht drumrum.
Aber du hast ja ganz sicher die Konfig VOR dem Umschalten aufs Filtering intelligenterweise gesichert und kannst die dann ganz schnell wieder mit einem simplen Mausklick einspielen !
Also HW Reset und neu konfigurieren?
Kommt drauf an... Hast du noch ein Interface was ggf. noch auf die WinBox reagiert ?? Ggf. alle durchprobieren.Man sollte sich immer ein Notfall Interface mit der Standard Konfig belassen BEVOR man umschaltet auf Filtering.
Wenn nichts mehr reagiert kommst du um einen Reset nicht drumrum.
Aber du hast ja ganz sicher die Konfig VOR dem Umschalten aufs Filtering intelligenterweise gesichert und kannst die dann ganz schnell wieder mit einem simplen Mausklick einspielen !
Habe alles durchprobiert, no way. Aber jetzt wusste ich ja wie ich alles einstellen musste. Und natürlich hatte ich noch kein Backup erstellt (war ja noch nicht fertig konfiguriert). #lessonlernt
Welche einstellungen muss ich treffen, dass der AP nur ausm dem MGMT Netz bearbeitet werden kann?
Du musst dein Management Interface in die Interface Liste "LAN" mit aufnehmen. Die WinBox Connection ist(im Default Setup) nur erlaubt auf Interfaces die Mitglieder dieser Liste sind.
Dort sollte also das Management VLAN IP Interface enthalten sein sofern der Mikrotik mit VLANs routet.
Bei einem normalen L2 Switching steht dort das HW Interface drin (Beispiel hier ether4).
(WinBox Mac Server ist unter Tools --> Mac Server)
So ist rein nur vom ether4 der Zugriff möglich mit der WinBox
Dort sollte also das Management VLAN IP Interface enthalten sein sofern der Mikrotik mit VLANs routet.
Bei einem normalen L2 Switching steht dort das HW Interface drin (Beispiel hier ether4).
So ist rein nur vom ether4 der Zugriff möglich mit der WinBox
Bei mir ist unter [Interface List] nichts eingetragen....
(das MGMT VLAN ist unter Bridge/VLANs noch nicht eingetragen.... hab noch Angst meine Config zu zerschießen)
(das MGMT VLAN ist unter Bridge/VLANs noch nicht eingetragen.... hab noch Angst meine Config zu zerschießen)
OK, dann arbeitest du ohne die Default Konfig. Nur diese hat diese Listen mit Restriktionen. Mit einer ganz nackigen Konfig gibt es diese Listen nicht und da ist dann alles offen. Dann ist das obige nicht relevant.
Hier kann man nur vermuten das du einen Bridging Fehler gemacht hast in der Konfig. Die Layer 2 Broadcasting Frames des Mac Servers können dann deine WinBox nicht erreichen wenn du mit Layer 2 (Mac Adresse) Autodetection in der WinBox arbeitest.
Dort ist es dann immer hilfreich die IP Adresse manuell einzutragen um zu connecten. Klappt das auch nicht dann hast du einen VLAN Bridging Error, denn dann kann man das VLAN IP Interface nicht erreichen.
Solltest du dann auch daran sehen das du dann keine DHCP IP bekommst und auch das zum VLAN korrespondierende VLAN IP Interface nicht pingen kannst sofern du VLAN Routing machst.
Hier kann man nur vermuten das du einen Bridging Fehler gemacht hast in der Konfig. Die Layer 2 Broadcasting Frames des Mac Servers können dann deine WinBox nicht erreichen wenn du mit Layer 2 (Mac Adresse) Autodetection in der WinBox arbeitest.
Dort ist es dann immer hilfreich die IP Adresse manuell einzutragen um zu connecten. Klappt das auch nicht dann hast du einen VLAN Bridging Error, denn dann kann man das VLAN IP Interface nicht erreichen.
Solltest du dann auch daran sehen das du dann keine DHCP IP bekommst und auch das zum VLAN korrespondierende VLAN IP Interface nicht pingen kannst sofern du VLAN Routing machst.
Ich habe mich an deinen Rat (aus einem anderem Tuturial), die Standard Config zu löschen...
WLAN und VLAN funktionieren soweit, bekomm auf jedem WLAN die passende IP vom DHCP des VLANs.
Autodetection/Winbox geht nur wenn ich mein Patchkabel auf einen "Trunkport" (wo 1UP konfiguriert ist) umstecke... (ab unter den Tisch)
WLAN und VLAN funktionieren soweit, bekomm auf jedem WLAN die passende IP vom DHCP des VLANs.
Autodetection/Winbox geht nur wenn ich mein Patchkabel auf einen "Trunkport" (wo 1UP konfiguriert ist) umstecke... (ab unter den Tisch)
wenn ich mein Patchkabel auf einen "Trunkport" (wo 1UP konfiguriert ist) umstecke...
Bedeutet dann das er den MT im VLAN 1 connectet denn ungetaggte Frames werden an dem Port dann in das VLAN geforwardet (1UP).Wie gesagt, der MT ist OHNE Default Konfig aber auch aus ALLEN anderen VLANs mit der WinBox zu erreichen. Wenn nicht und das IP Interface pingbar ist, dann ist es so gut wie immer die lokale Winblows Firewall die diesen Traffic blockiert. Im Zweifel, wie gesagt, immer die IP Adresse als Connect Ziel in der WB eingeben dann klappt es sicher sofern IP Cinnectivity da ist.
Zitat von @aqui:
So, habe es eben mal nachgestellt auf der pfSense mit dem FreeRadius Package.
Es erfordert etwas "Handarbeit", klappt dann aber fehlerfrei.
Mit den folgenden ToDos bekommst du das zum Fliegen:
Du connectest die pfSense über das serielle Terminal oder von extern über den SSH Shell Zugang mit PuTTY und erstellst mit dem vi Editor eine separate User Datei z.B. users.test
Noch einfacher ist es diese Datei mit einem Editor eigener Wahl wie z.B. Notepad++ vorher sauber zu editieren und dann ganz einfach mit einem grafischen Copy Tool wie z.B. dem Klassiker WinSCP per Drag and Drop direkt auf die Firewall zu kopieren. Am Besten ins Verzeichnis /usr/local/etc/raddb Wo die originale User Datei ist.
Ist das erledigt kannst du mit einem Trick die original User Datei anpassen. FreeRadius erlaubt mit dem "$Include" Parameter externe, eigene User Dateien zu Importieren. Das hebelt elegant das Überschreiben der User Konfig Datei im GUI aus.
Du legst einen einzigen exotischen Dummy User dort an und in den Parametern definierst du deine eigene User Datei mit $INCLUDE /usr/local/etc/raddb/users.test was dann so aussieht:
Fertisch !
Der Rest ist dann Standard
ACHTUNG !!!: Das hier ist nur ein Schnellschuss Beispiel. Nicht nachmachen !
Im Produktivnetz sollte man unter Interface IP immer die dedizierte IP des lokalen Ports eintragen über den der Radius Request auf die pfSense eingeht. In der Regel ist das einer der lokalen LAN Ports.
Natürlich sollte dort auch eine entsprechende Regel existieren die den Radius Request passieren lässt.
Der "*" erlaubt den Zugang über alle Interfaces, also auch den WAN Port was sicher keine gute Idee ist !
Das wars !
Das rennt dann fehlerfrei.
Natürlich kann man auch wunderbar den Radius Server auf der pfSense troubleshooten wenn das einmal erforderlich sein sollte !
Dazu geht man wieder auf die Shell über Seriell oder SSH mit PuTTY und checkt mit ps ax | grep radiusd welche Process ID der Radius Server hat.
Danach killt man den Prozess mit kill <process_id> Ist zwar nicht ganz die feine englische Art unter Unix, erfüllt aber seinen Zweck.
Dann startet man wie beim Debuggen üblich mit radiudsd -X den FreeRadius manuell im Debugging Mode und kann dann anhand der Meldungen sehr genau sehen was schief geht. Wenn denn überhaupt etwas schief geht...
So, habe es eben mal nachgestellt auf der pfSense mit dem FreeRadius Package.
Es erfordert etwas "Handarbeit", klappt dann aber fehlerfrei.
Mit den folgenden ToDos bekommst du das zum Fliegen:
1.) Separate User Datei über den Shell Zugang erstellen:
Du connectest die pfSense über das serielle Terminal oder von extern über den SSH Shell Zugang mit PuTTY und erstellst mit dem vi Editor eine separate User Datei z.B. users.testNoch einfacher ist es diese Datei mit einem Editor eigener Wahl wie z.B. Notepad++ vorher sauber zu editieren und dann ganz einfach mit einem grafischen Copy Tool wie z.B. dem Klassiker WinSCP per Drag and Drop direkt auf die Firewall zu kopieren. Am Besten ins Verzeichnis /usr/local/etc/raddb Wo die originale User Datei ist.
[root@pfSense.test.home.arpa]/usr/local/etc/raddb: cat users.test
> # Mikrotik Mac Auth and dyn. VLAN
> # Mac Format XXXX:XXXX:XXXX
> #
> 0022:FA7B:1234 Cleartext-Password := "0022:FA7B:1234"
> Tunnel-Type = VLAN,
> Tunnel-Medium-Type = IEEE-802,
> Mikrotik-Wireless-VLANID := 10,
> Mikrotik-Wireless-Comment = "hp"
> #
> 0021:857E:5678 Cleartext-Password := "0021:857E:5678"
> Tunnel-Type = VLAN,
> Tunnel-Medium-Type = IEEE-802,
> Mikrotik-Wireless-VLANID := 20,
> Mikrotik-Wireless-Comment = "msi"
> #
> DEFAULT Cleartext-Password := "%{User-Name}"
> Tunnel-Type = VLAN,
> Tunnel-Medium-Type = IEEE-802,
> Mikrotik-Wireless-VLANID := 99,
> Mikrotik-Wireless-Comment = "unknown" 2.) Users Datei im GUI anpassen:
Ist das erledigt kannst du mit einem Trick die original User Datei anpassen. FreeRadius erlaubt mit dem "$Include" Parameter externe, eigene User Dateien zu Importieren. Das hebelt elegant das Überschreiben der User Konfig Datei im GUI aus. Du legst einen einzigen exotischen Dummy User dort an und in den Parametern definierst du deine eigene User Datei mit $INCLUDE /usr/local/etc/raddb/users.test was dann so aussieht:
Der Rest ist dann Standard
3.) Interfaces für den Radius Zugriff aktivieren:
Im Produktivnetz sollte man unter Interface IP immer die dedizierte IP des lokalen Ports eintragen über den der Radius Request auf die pfSense eingeht. In der Regel ist das einer der lokalen LAN Ports.
Natürlich sollte dort auch eine entsprechende Regel existieren die den Radius Request passieren lässt.
Der "*" erlaubt den Zugang über alle Interfaces, also auch den WAN Port was sicher keine gute Idee ist !
4.) Check ob der Radius Server aktiv ist:
Das wars !
Das rennt dann fehlerfrei.
5.) Zusatzinfo Troubleshooting:
Natürlich kann man auch wunderbar den Radius Server auf der pfSense troubleshooten wenn das einmal erforderlich sein sollte !Dazu geht man wieder auf die Shell über Seriell oder SSH mit PuTTY und checkt mit ps ax | grep radiusd welche Process ID der Radius Server hat.
[root@TestSense.lab.home.arpa]/usr/local/etc/raddb: ps ax | grep radiusd
> 87534 - Is 0:00.31 /usr/local/sbin/radiusd
> 88924 u0 R+ 0:00.00 grep radiusd
> [root@TestSense.lab.home.arpa]/usr/local/etc/raddb: kill 87534 Dann startet man wie beim Debuggen üblich mit radiudsd -X den FreeRadius manuell im Debugging Mode und kann dann anhand der Meldungen sehr genau sehen was schief geht. Wenn denn überhaupt etwas schief geht...
Grüße.
Bin gestern erst auf diesen Thread gestoßen.
Wollte nur mal anmerken, daß ich für die OPNsense das FreeRADIUS Paket vor etwa drei Jahren von einem Entwickler angepaßt bekommen habe. Damit braucht man die VLAN's nicht mehr manuell in die Datenbank eintragen.
Danke für diese wertvolle Info ! 😉
OPNsense wird immer besser...
OPNsense wird immer besser...