59
CaptivePortal-Frage zu Ubiquiti und FritzBox
Hallo zusammen,
ich komme gerade nicht weiter. Ich möchte den Ubiquiti-Hotspot mit Voucher-Anmeldung in folgender Konstellation nutzen:
Die Unifi-AccessPoints strahlen zwei Netze aus, einmal INTERN und einmal GAST.
Für das wLAN GAST sind die Gastrichtlnien, also vor allem das CaptivePortal aktiviert.
INTERN gehört zum Netzwerk DEFAULT und GAST zum Netzwerk GASTNETZ mit der vLAN-ID 40
Das Netzwerk Default hat den IP-Bereich 10.200.0.0/22 und wird an einem entsprechend konfigurierten Port eines Unifi-Switches auf Port 2 der FritzBox ausgegeben.
Das Netzwerk Default hat den IP-Bereich 192.168.179.0/24 und wird an einem entsprechend konfigurierten Port eines Unifi-Switches auf Port 4 der FritzBox ausgegeben. Auf der FritzBox ist Gastzugang auf LAN4 aktiviert.
Für beide Netzw spielt die FritzBox den DHCP-Server.
Der Unifi-Cloudkey als Controller hängt an einem Port eines Unifi-Switches, der beide vLANs ausgibt.
Wenn ich mich nun mit einem Tablet mit dem wLAN GAST verbinde, zeigt Android korrekt an, dass dafür eine Anmeldung erforderlich ist. Aber er zeigt dann die Captive-Portal-Anmeldeseite nicht an - vermutlich, weil ich durch die Verbindung mit GAST eine IP aus dem Gastnetz (192.168.179.0/24) erhalten habe, der Cloudkey, auf dem das CaptiovePortal gehostet wird, aber eine IP im internen Netz hat (10.200.0.100).
Ich bin sicher, dass es dafür eine Lösung gibt, denn dass das Gastnetz einen anderen IP-Adressbereich hat als das interne Netz ist ja normal. Aber welchen?
Alternativ Kann ich in der FritzBox einstellen, dass aus dem Gastnetz heraus eine einzelne IP-Adresse im internen Netz (nämlich der Cloudkey) erreichbar ist?
Danke im Voraus,
Sarek \\//_
ich komme gerade nicht weiter. Ich möchte den Ubiquiti-Hotspot mit Voucher-Anmeldung in folgender Konstellation nutzen:
Die Unifi-AccessPoints strahlen zwei Netze aus, einmal INTERN und einmal GAST.
Für das wLAN GAST sind die Gastrichtlnien, also vor allem das CaptivePortal aktiviert.
INTERN gehört zum Netzwerk DEFAULT und GAST zum Netzwerk GASTNETZ mit der vLAN-ID 40
Das Netzwerk Default hat den IP-Bereich 10.200.0.0/22 und wird an einem entsprechend konfigurierten Port eines Unifi-Switches auf Port 2 der FritzBox ausgegeben.
Das Netzwerk Default hat den IP-Bereich 192.168.179.0/24 und wird an einem entsprechend konfigurierten Port eines Unifi-Switches auf Port 4 der FritzBox ausgegeben. Auf der FritzBox ist Gastzugang auf LAN4 aktiviert.
Für beide Netzw spielt die FritzBox den DHCP-Server.
Der Unifi-Cloudkey als Controller hängt an einem Port eines Unifi-Switches, der beide vLANs ausgibt.
Wenn ich mich nun mit einem Tablet mit dem wLAN GAST verbinde, zeigt Android korrekt an, dass dafür eine Anmeldung erforderlich ist. Aber er zeigt dann die Captive-Portal-Anmeldeseite nicht an - vermutlich, weil ich durch die Verbindung mit GAST eine IP aus dem Gastnetz (192.168.179.0/24) erhalten habe, der Cloudkey, auf dem das CaptiovePortal gehostet wird, aber eine IP im internen Netz hat (10.200.0.100).
Ich bin sicher, dass es dafür eine Lösung gibt, denn dass das Gastnetz einen anderen IP-Adressbereich hat als das interne Netz ist ja normal. Aber welchen?
Alternativ Kann ich in der FritzBox einstellen, dass aus dem Gastnetz heraus eine einzelne IP-Adresse im internen Netz (nämlich der Cloudkey) erreichbar ist?
Danke im Voraus,
Sarek \\//_
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671619
Url: https://administrator.de/forum/captiveportal-frage-zu-ubiquiti-und-fritzbox-671619.html
Ausgedruckt am: 28.03.2025 um 22:03 Uhr
59 Kommentare
Neuester Kommentar
Moin,
über die Fritz!Box: nein. Das ist ja gerade der Sinn, dass die Fritz!Box das Gastnetz vom übrigen Netz abschirmt und nur Verkehr zum WAN/Internet durchlässt.
Da muss also vorher in der Kette ein Routing stattfinden.
Gruß
DivideByZero
Alternativ Kann ich in der FritzBox einstellen, dass aus dem Gastnetz heraus eine einzelne IP-Adresse im internen Netz (nämlich der Cloudkey) erreichbar ist?
über die Fritz!Box: nein. Das ist ja gerade der Sinn, dass die Fritz!Box das Gastnetz vom übrigen Netz abschirmt und nur Verkehr zum WAN/Internet durchlässt.
Da muss also vorher in der Kette ein Routing stattfinden.
Gruß
DivideByZero
So ein Szenario ist grundsätzlich HIER beschrieben.
Grundlagen zu einem MSSID AP Setup, wie du es betreibst, findest du HIER.
Ein häufiger Fehler der oftmals begangen wird ist der falsche Umgang mit dem Default VLAN 1 an AP und auch am korrespondierenden Switchport.
Der Anschlussport der APs muss im Trunk Mode konfiguriert sein mit dem PVID 1. Sprich also Traffic vom Default VLAN 1 wird dort UNtagged gesendet aber der Gasttraffic dann mit deinem VLAN 40 Tag in deinem Fall.
Das VLAN 1 darf dort nicht oder fälschlicherweise zum PVID 1 zusätzlich getagged sein, was dann sofort zur Fehlfunktion führt.
Achte also auf die korrekte Konfiguration der AP Ports und der dazu korrespondierenden Switchports.
Da die Fritte keinerlei VLAN Support kennt musst du von der natürlich dann 2 separate Patchstrippen vom LAN und LAN 4 Port auf den VLAN Switch legen. Diese Switchports müssen als reine Accessports also UNtagged mit PVID 1 und PVID 40 gesetzt sein für das Default VLAN und das Gastnetz.
Es macht Sinn diese beiden netze mit einem Test PC am Switch vorab zu testen indem man den PC abwechselnd ins VLAN 1 und VLAN 40 steckt und dabei mit ipconfig checkt ob die IP Adressvergabe korrekt ist. Das stellt sicher das beide Netze sauber in ihren dafür vorgesehenen VLANs arbeiten!
Das Gastnetz sollte man keinesfalls auf einem Router oder Firewall mit einem L3 Interface anbinden. Genau DAS will man ja mit Gastnetzen keinesfalls, weil das dann zusätzlichen Aufwand in der Firewall Konfig erzwingt um dieses Netz wasserdicht von den privaten Netzen zu trennen. Fehler im Regelwerk können dann fatale Folgen haben.
Genau deshalb macht es also sehr viel Sinn dieses VLAN 40 Gastnetz lediglich im Layer 2 über die Switchinfrastruktur "durchzuschleifen" und L3technisch ausschliesslich nur auf der Fritte zu terminieren was dann Regeln per se obsolet macht.
So ist das Gastnetz immer wasserdicht vom privaten Netz getrennt.
Grundlagen zu einem MSSID AP Setup, wie du es betreibst, findest du HIER.
Ein häufiger Fehler der oftmals begangen wird ist der falsche Umgang mit dem Default VLAN 1 an AP und auch am korrespondierenden Switchport.
Der Anschlussport der APs muss im Trunk Mode konfiguriert sein mit dem PVID 1. Sprich also Traffic vom Default VLAN 1 wird dort UNtagged gesendet aber der Gasttraffic dann mit deinem VLAN 40 Tag in deinem Fall.
Das VLAN 1 darf dort nicht oder fälschlicherweise zum PVID 1 zusätzlich getagged sein, was dann sofort zur Fehlfunktion führt.
Achte also auf die korrekte Konfiguration der AP Ports und der dazu korrespondierenden Switchports.
Da die Fritte keinerlei VLAN Support kennt musst du von der natürlich dann 2 separate Patchstrippen vom LAN und LAN 4 Port auf den VLAN Switch legen. Diese Switchports müssen als reine Accessports also UNtagged mit PVID 1 und PVID 40 gesetzt sein für das Default VLAN und das Gastnetz.
Es macht Sinn diese beiden netze mit einem Test PC am Switch vorab zu testen indem man den PC abwechselnd ins VLAN 1 und VLAN 40 steckt und dabei mit ipconfig checkt ob die IP Adressvergabe korrekt ist. Das stellt sicher das beide Netze sauber in ihren dafür vorgesehenen VLANs arbeiten!
Das Gastnetz sollte man keinesfalls auf einem Router oder Firewall mit einem L3 Interface anbinden. Genau DAS will man ja mit Gastnetzen keinesfalls, weil das dann zusätzlichen Aufwand in der Firewall Konfig erzwingt um dieses Netz wasserdicht von den privaten Netzen zu trennen. Fehler im Regelwerk können dann fatale Folgen haben.
Genau deshalb macht es also sehr viel Sinn dieses VLAN 40 Gastnetz lediglich im Layer 2 über die Switchinfrastruktur "durchzuschleifen" und L3technisch ausschliesslich nur auf der Fritte zu terminieren was dann Regeln per se obsolet macht.
So ist das Gastnetz immer wasserdicht vom privaten Netz getrennt.
Ja, sehr grundsätzlich. Da ist andere Hardware im Spiel, ich möchte nur mit der Ubiquiti-Hardware und der FritzBox auskommen.
Da die Fritte keinerlei VLAN Support kennt musst du von der natürlich dann 2 separate Patchstrippen vom LAN und LAN 4 Port auf den VLAN Switch legen.
Richtig.
Diese Switchports müssen als reine Accessports also UNtagged mit PVID 1 und PVID 40 gesetzt sein für das Default VLAN und das Gastnetz.
Richtig, hier am Beispiel des Internen Netzes:
Ein häufiger Fehler der oftmals begangen wird ist der falsche Umgang mit dem Default VLAN 1 an AP und auch am korrespondierenden Switchport.
Der Anschlussport der APs muss im Trunk Mode konfiguriert sein mit dem PVID 1. Sprich also Traffic vom Default VLAN 1 wird dort UNtagged gesendet aber der Gasttraffic dann mit deinem VLAN 40 Tag in deinem Fall.
Das ist alles richtig und funktioniert auch. Solange das Gast-wLAN auch ein normales, WPA3-verschlüsseltes Netz ist, funktioniert es super, genau wie es soll.
Das Problem ist der Zugriff auf den CloudKey (IP-Adresse aus dem internen Netz) vom Gastnetz aus. Dieser Zugriff scheint (das ist meine Vermutung) der Grund dafür zu sein, dass die Captive-Portal-Begrüßungsseite, auf der man seinen Voucher eingeben muss, nicht angezeigt wird. Aber der Cloudkey liefert diese Seite ja aus. Also muss die Anfrage aus dem Gastnetz irgendwie dahin geroutet werden - aber wie? Ich finde da keine Option in der Controller-Software. Oder kann man dem Cloudkey eine zweite IP-Adresse (im Gastnetz) geben?
Wie soll es denn auch? Das Gast-Netz hat doch keinen Übergang in das private Netz, und da läuft doch der Cloudkey, oder habe ich das falsch verstanden?
Zitat von @DivideByZero:
Wie soll es denn auch? Das Gast-Netz hat doch keinen Übergang in das private Netz, und da läuft doch der Cloudkey, oder habe ich das falsch verstanden?
Wie soll es denn auch? Das Gast-Netz hat doch keinen Übergang in das private Netz, und da läuft doch der Cloudkey, oder habe ich das falsch verstanden?
Jein ... grundsätzlich ist der Switchport, an drm der Cloudkey hängt, in beiden vLANs. Aber vom IP-Bereich her eben nicht.
Nur - dafür muss es doch (auch innerhalb des Systems UniFi, ohne noch eine pfSense oder ähnliches dazwischenzuhängen) eine Lösung geben! Ein Gastnetz ist doch der typische Anwendungsfall für ein CaptivePortal. Das Ding heißt in der deutschen Übersetzung des UniFi-Controllers ja sogar "Gaststeuerung".
Ja, sicher, nur nicht mit der Fritz!box. Die schottet ja nun einmal gegeneinander ab.
Was Du benötigst, ist ein Übergang von einem VLAN in das andere, und zwar nur und ausschließlich begrenzt auf den Cloudkey (der ist dann ja angreifbar!) und nicht den Rest. Oder alternativ den Cloudkey nur im Gastnetz nutzen, aber dann fällt die Funktionalität im Lan weg...
Was Du benötigst, ist ein Übergang von einem VLAN in das andere, und zwar nur und ausschließlich begrenzt auf den Cloudkey (der ist dann ja angreifbar!) und nicht den Rest. Oder alternativ den Cloudkey nur im Gastnetz nutzen, aber dann fällt die Funktionalität im Lan weg...
Zitat von @DivideByZero:
Ja, sicher, nur nicht mit der Fritz!box. Die schottet ja nun einmal gegeneinander ab.
Ja, sicher, nur nicht mit der Fritz!box. Die schottet ja nun einmal gegeneinander ab.
Ich hatte eigentlich angenommen, dass es innerhalb der UniFi-Hardware, also bevor das ganze zur FritzBox geht, eine Lösung gibt. Ich glaube, ich frage mal in einem Ubiquit-Forum ...
Solange Du keinen Router mit VLAN Unterstützung hast, nein
Doch diese Lösung gibt es natürlich und ist auch kinderleicht.
Es ist ja quasi eine Dual WAN Lösung.
Da die Fritte keine VLANs supportet musst du an der UniFi Gurke 2 WAN Ports definieren.
Die UniFi Gurke "sieht" dann quasi 2 Internet Verbindungen, einmal die "normale" über den Fritzbox LAN Port und einmal die über den LAN4 Port (Gast)
Die Gast WAN Verbindung muss zwingend geNATet werden auf dem UniFi Router da keine statischen Routen der Fritte dort greifen.
Der WAN Port über das LAN Interface kann mit oder auch ohne NAT betrieben werden.
Auf dem Unify Router/Firewall legt man dann eine einfache Policy Route an die allen Traffic mit einer Absender IP aus dem Gastnetz Segment über den WAN Port am LAN4 Frittenport sendet und alles andere über den LAN Frittenport sendet. Fertisch...
So kannst du problemlos mit dem Ticketsystem im Gastnetz arbeiten
Eigentlich doch ein simples und klassisches Design auf das man mit dem gesunden IT Verstand auch selber kommt.
Es ist ja quasi eine Dual WAN Lösung.
Da die Fritte keine VLANs supportet musst du an der UniFi Gurke 2 WAN Ports definieren.
Die UniFi Gurke "sieht" dann quasi 2 Internet Verbindungen, einmal die "normale" über den Fritzbox LAN Port und einmal die über den LAN4 Port (Gast)
Die Gast WAN Verbindung muss zwingend geNATet werden auf dem UniFi Router da keine statischen Routen der Fritte dort greifen.
Der WAN Port über das LAN Interface kann mit oder auch ohne NAT betrieben werden.
Auf dem Unify Router/Firewall legt man dann eine einfache Policy Route an die allen Traffic mit einer Absender IP aus dem Gastnetz Segment über den WAN Port am LAN4 Frittenport sendet und alles andere über den LAN Frittenport sendet. Fertisch...
So kannst du problemlos mit dem Ticketsystem im Gastnetz arbeiten
Eigentlich doch ein simples und klassisches Design auf das man mit dem gesunden IT Verstand auch selber kommt.
Moin Aqui,
vielleicht habe ich etwas falsch verstanden, aber wo ist denn in dem Setup ein Router abseits der Fritzbox?
vielleicht habe ich etwas falsch verstanden, aber wo ist denn in dem Setup ein Router abseits der Fritzbox?
Hatt er oben nicht irgendwas von einer gruseligen UniFi Kiste Firewall etc. geschrieben? Wer sollte sonst ein Captive Portal mit einem Ticketsystem bereitstellen, das kann in der Regel immer nur ein Router oder eine Firewall also ein L3 Device.
OK, nur mit einer nackten Layer 2 VLAN Switchinfrastruktur und nur mit einer Fritte die sowas nicht supportet ist das natürlich nicht machbar, da hast du zweifelsohne Recht!
OK, nur mit einer nackten Layer 2 VLAN Switchinfrastruktur und nur mit einer Fritte die sowas nicht supportet ist das natürlich nicht machbar, da hast du zweifelsohne Recht!
Ok, neuer Versuch - diesmal mit einem Mikrotik als Zwischenrouter für das Gastnetz (rot):
- Die Pakete für das Gastnetz kommen auf Port 3 (rote Linie) an
- nur die Pakete für den Controller werden in das interne Netz (blaue Linie) geroutet
- aus dem roten Netz kommende Pakete für das Internet werden an das Gastnetz der FritzBox (grüne Linie) geroutet
Fragen
- Die Pakete für das Gastnetz kommen auf Port 3 (rote Linie) an
- nur die Pakete für den Controller werden in das interne Netz (blaue Linie) geroutet
- aus dem roten Netz kommende Pakete für das Internet werden an das Gastnetz der FritzBox (grüne Linie) geroutet
Fragen
- Kann ein einfacher Mikrotik (z.B. der hEX RB750Gr3, den ich mal zum "herumspielen" gekauft hatte, oder der RB951UI-2HnD) das? Also drei verschiedene Netze mit den beiden beschriebenen Routings handhaben ...
- Kann der Mikrotik auch DHCP-Server spielen? Denn in der Konstellation kann die FritzBox ja nicht DHCP-Server für das rote Netz sein.
Ergänzung: Ich habe auch noch ein mindestens zehn Jahre altes Alix-Board mit drei LAN-Anschlüssen rumliegen - vielleicht geht auch damit was? Ich bräuchte bloß ganz viel Hilfe bei er Einrichtung, weil ich von Routing relativ wenig Ahnung habe, vor allem wenn es wie in meinem Beispiel oben um ein Zwei-Wege-Routing geht ...
Zu 1.
Ja, natürlich kann er das. Jeder Router OS basierte Mikrotik kann das. Unabhängig von der Plattform
Zu 2.
Ja natürlich. Mit oder ohne VLANs wie du es gerne möchtest... Tutorials und seine weiterführenden Links zu solchen Praxissetups im Forum liest du vermutlich nicht, oder...?!
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Wenn du es ganz toll machst kannst du dem Mikrotik Gastnetz sogar noch ein schickes Captive Portal (Hotspot) mit einer User Authentsierung und Einmalpasswörtern spendieren.
Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik
Allerdings fragt man sich wie es sein kann das du als FritzBox "Router" User diese bedienst wenn du nichts übers Routing weisst?!
Du könntest uns aber entgegenkommen wenn du zumindestens schon einmal die ganz einfachen Grundlagen zum IP Routing lesen und verstehen würdest. Dann müssen wir das Rad nicht 2mal erfinden.
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Noch ein Tip:
Bevor du den Mikrotik einsatzklar machst für das o.a. Setup date ihn mit dem WinBox Konfig Tool auf die aktuelle Stable Version up: https://mikrotik.com/download
Für einen RB750gr3 benötigst du das MIPSBE Image oder lädst es online über den Menüpunkt "Package" direkt auf den Router.
Das aktuelle WinBox Konfig Tool kannst du dort auch runterladen!
Ja, natürlich kann er das. Jeder Router OS basierte Mikrotik kann das. Unabhängig von der Plattform
Zu 2.
Ja natürlich. Mit oder ohne VLANs wie du es gerne möchtest... Tutorials und seine weiterführenden Links zu solchen Praxissetups im Forum liest du vermutlich nicht, oder...?!
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Wenn du es ganz toll machst kannst du dem Mikrotik Gastnetz sogar noch ein schickes Captive Portal (Hotspot) mit einer User Authentsierung und Einmalpasswörtern spendieren.
Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik
Ich bräuchte bloß ganz viel Hilfe bei er Einrichtung, weil ich von Routing relativ wenig Ahnung habe
Dafür ist ein Forum wie dieses ja da! 😉Allerdings fragt man sich wie es sein kann das du als FritzBox "Router" User diese bedienst wenn du nichts übers Routing weisst?!
Du könntest uns aber entgegenkommen wenn du zumindestens schon einmal die ganz einfachen Grundlagen zum IP Routing lesen und verstehen würdest. Dann müssen wir das Rad nicht 2mal erfinden.
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Noch ein Tip:
Bevor du den Mikrotik einsatzklar machst für das o.a. Setup date ihn mit dem WinBox Konfig Tool auf die aktuelle Stable Version up: https://mikrotik.com/download
Für einen RB750gr3 benötigst du das MIPSBE Image oder lädst es online über den Menüpunkt "Package" direkt auf den Router.
Das aktuelle WinBox Konfig Tool kannst du dort auch runterladen!
Zitat von @aqui:
Ja, natürlich kann er das. Jeder Router OS basierte Mikrotik kann das. Unabhängig von der Plattform
Ja, natürlich kann er das. Jeder Router OS basierte Mikrotik kann das. Unabhängig von der Plattform
Das ist gut ... das heißt ich kann die drei Ports dieses Routers separat programmieren. Das habe ich inzwischen mit dieser Anleitung (einer der wenigen deutschsprachigen) angefangen:
Jetzt wollte ich auf das Unifi-Gastnetz einen DHCP-Server setzen und scheitere, weil das auf einem Slave-Interface nicht geht. Dazu wiederum nachgelesen bedeutet das offenbar, dass die alle gebridgt sind. Wie kann ich das ändern? In Deiner Anleitung, die ich mir gleich mal zu Gemüte führen will, taucht das Wort Slave nicht auf.
Wenn du es ganz toll machst kannst du dem Mikrotik Gastnetz sogar noch ein schickes Captive Portal (Hotspot) mit einer User Authentsierung und Einmalpasswörtern spendieren.
Dann könnte ich mir das ganze sparen, ich möchte ja, dass die Gastnetz-Clients das CaptivePortal des Unifi-Controller nutzen können, nur deshalb soll der CloudKey ja aus dem Gastnetz erreichbar werden
Allerdings fragt man sich wie es sein kann das du als FritzBox "Router" User diese bedienst wenn du nichts übers Routing weisst?!
Nichts ist sicher übertrieben. Grundsätzlich weiß ich schon, was Routing, und wie ich es auf einem Windows-Server einrichten könnte, in diesem Fall wohl:
- Route auf 10.200.0.5/32 (der Cloudkey) über Interface 10.200.0.2 metric 0
- Router 0.0.0.0/0 (Internet) über Interface 192.168.179.10 metric 1
(Achtung, durch die neue Konstellation hätte das Unifi-Gastnetz jetzt die Adresse 192.168.40.0/24)
Aber ich weiß eben nicht, wie man sowas auf Miktrotik umsetzt. Mal sehen, ob ich dem mit Deiner Anleitung näher komme ...
das heißt ich kann die drei Ports dieses Routers separat programmieren.
Richtig!Solange das keine Member Ports einer Bridge oder VLANs sind ja.
Im Default (ohne Default Konfig) ist der Mikrotik immer ein Router und jeder Port kann/darf ein dedizierter Routing Port mit entsprechender IP Adresse sein. Hast du oben ja auch schon entsprechend richtig gemacht!
⚠️ Achtung:
Deine o.a. Konfig lässt stark vermuten das du vergessen hast die Default Konfig im Router vorher zu löschen!! 🤔
Wie man unschwer erkennen kann geistert da noch eine Bridge und Bezeichnungen wie "defconf,,," rum die das mehr oder minder bestätigen. Ein reiner Router kennt sowas wie eine Bridge bekanntlich nicht.
Damit ist dann eine Router Port Konfig auf den einzelnen Interfaces NICHT möglich weil die bestehende Default Konfig die Ports anderweitig vorkonfiguriert!! Ein Port kann logischerweise nicht gleichzeit Bridgeport und Routerport sein!!!
Die Default Konfig macht folgendes wenn man sie nicht VOR dem Reset löscht:
- Port ether1 = WAN Port mit aktiver Firewall, NAT (Adress Translation), DHCP Client Mode. Connect ist hier durch die aktive Firewall weder mit GUI noch Winbox möglich!
- Ports 2 bis 5 = Sind zu einer Bridge zusammengefasst, IP auf Bridgeport, DHCP Server auf der Bridge aktiviert mit Default IP Netz 192.168.88.0 /24
Leider hast du es wohl versäumt beide Tutorials zu mindestens ansatzweise einmal zu lesen!!
Du kannst auch mühselig alle Default Konfigs über das GUI oder Winbox entfernen aber das ist mühevoll und mit einem einfachen Werksreset und Haken bei no default config deutlich einfacher.
Jetzt wollte ich auf das Unifi-Gastnetz einen DHCP-Server setzen
Welches denn?? Du hast ja oben schliesslich 2 IP Netze die gleichermaßen so heissen! ❗️ Nochmals die Wiederholung des Tips von oben:
Benutze als Mikrotik Anfänger wenn immer möglich das Winbox Konfig Tool!
Dies hat den großen Vorteil das es auch ganz ohne IP Verbindung, rein über den Layer 2 den Mikrotik automatisch erkennt und du auf ihn zugreifen kannst ohne das eine IP Verbindung/Adressierung bestehen muss. Ein wesentlicher Vorteil gegenüber dem WebGUI was IP voraussetzt!
Ganz besonders wenn man die Default Konfig löscht, denn dann hast du natürlich keinerlei IP Adressen und DHCP Server mehr auf der Kiste!! Die WinBox ist dann aus Sicht der Konfig lebenswichtig für einen Anfänger!!
Der MT ist keine Allerwelts KlickiBunti Plaste Fritte sondern hat konfigtechnisch Cisco Niveau. Entsprechend steil ist die Lernkurve. Wenn du Hilfe brauchst solltest du diese auch annehmen...
Deine ToDos:
- Winbox installieren und mit deinem RB750er testen. (Bei Winblows achte darauf das WinBox in der lokalen Firewall frei ist! Teste es vorab mit deinem bestehenden RB bevor du an den Reset gehst.)
- Werksreset im Menü "System" und Haken setzen ohne Default Konfig
- Mikrotik kommt dann nackig hoch ohne IPs kann aber über die Winbox gesehen und verbunden werden
- IP Adressen, wie du oben schon richtig gemacht hast, an den Ports deiner Wahl konfigurieren
- Für den DHCP Server klickst du ins Winbox Menü IP -> DHCP dort auf den großen Button "DHCP Setup". Hier kannst du dann für das jeweilige Interface deiner Wahl menügeführt den DHCP Server mit Range, Gateway, DNS usw. einrichten.
Danke für die ausführliche Erklärung.
Da kommt schon das erste Problem:
Bei der Gelegenheit:
Winbox installieren und mit deinem RB750er testen. (Bei Winblows achte darauf das WinBox in der lokalen Firewall frei ist! Teste es vorab mit deinem bestehenden RB bevor du an den Reset gehst.)
Da kommt schon das erste Problem:
Bei der Gelegenheit:
- Ich habe gelesen, dass man sich zum Programmieren des Gerätes über Port 2 verbinden soll. Wenn ich die Ports frei programmieren kann, kann ich das auch über Port 1 (über den ich das Gerät ja auch via PoE mit Strom versorgen kann) tun?*
- Macht es Sinn, auf diesen Port dann das interne LAN (auf das aus dem Gastnetz dann auch die Pakete für den CloudKey geroutet werden sollen) zu legen?
- Kann ich (sinnvollerweise) für dieses Netz die IP-Adresse per DHCP beziehen? Denn jetzt zuhause arbeite ich in einem anderen Netzwerk als jenes, in das der Router später eingebunden werden soll.
Da kommt schon das erste Problem:
no routeros.jg found
no routeros.jg found
ok, das Problem hat sich nach einem Update der Winbox (die hatte ich noch auf dem Rechner, offenbar eine veraltete Version) erledigt. Bevor ich weitermache würde ich aber trotzdem gerne Deinen Rat zu den anderen Fragen haben ... denn wenn ich Port ether1 für die Programmierung nutzen kann und dieser Port gleichzeitig ein Routingziel sein kann (nicht das Standard-Gateway!) würde das einiges erleichtern.
Ja, WinBox sollte immer auf der latest Version sein! Aktuell ist 3.4.1 wenn man mit der Stable Windows only Version arbeitet.
Zu deinen Fragen...
1.)
Wenn du OHNE Default Konfig arbeitest, also mit einem nackten System ohne jegliche Grundkonfig, dann ist es völlig egal welchen Port du zur Konfiguration wählst. Ohne eine bestehende Konfig sind ja per se alle Ports gleich. Welchen du dann nimmst spielt keinerlei Rolle.
OK, Ports die du für PoE nutzt musst du dann beachten aber netzwerktechnisch sind auch diese Ports gleichbereichtigt.
Das "Port 2 Thema" bezieht sich ganz sicher wieder auf ein System mit Default Konfig. Wäre dann aber auch etwas sinnfrei, denn da bei den kleineren Systemen die Ports 2-5 gleichberechtigt in einer Bridge zusammengefasst sind wäre es auch wieder egal innerhalb dieser Bridgeports.
2.)
Ja. Managementtechnisch gesehen könnte das Sinn machen, denn über den Port kommt ja dein Managementzugang wenn du ihn z.B. aus einem PoE Switch versorgst. Dieser Port sollte ja dann immer verfügbar sein.
Aber wie gesagt das wäre rein aus kosmetischer Managementsicht und wie du es für dich für richtig hälst. Netztechnisch sind auf einem nackten Router (ohne Default Konfig) alle Ports gleichermaßen geeignet weil sie eben allesamt gleichberechtigt sind.
3.)
Ja natürlich. Das klappt. Jeder dieser Ports kann als DHCP Client arbeiten!
Das konfigurierst du ganz einfach und klickst im Winbox Menü lediglich IP -> DHCP Client und aktivierst die Funktion auf dem Interface deiner Wahl. Im Konfig Fenster wirst du dann auch gleich die IP Zuteilung sehen sofern der Port in einem Netz mit DHCP aktiv ist.
Was wichtig ist in diesem Zusammenhang:
Da das ein Routerport ist muss man bei DHCP zugeteilten Routeradressen immer vorsichtig sein. Routen und Endgeräte verlassen sich drauf das Router IP Adressen fest sind damit die Wegefindung immer sauber funktioniert.
Bei per DHCP basierten Routeradressen solltest du dann immer darauf achten das es ein festes Binding auf die Mac Adresse gibt und der Router immer diese IP vom DHCP Server fest zugewiesen bekommt und sich das nicht ändert mit der DHCP Dynamik.
Wenn du bzw. der DHCP Server das beachtet spricht nichts gegen eine DHCP Vergabe.
Zu deinen Fragen...
1.)
Wenn du OHNE Default Konfig arbeitest, also mit einem nackten System ohne jegliche Grundkonfig, dann ist es völlig egal welchen Port du zur Konfiguration wählst. Ohne eine bestehende Konfig sind ja per se alle Ports gleich. Welchen du dann nimmst spielt keinerlei Rolle.
OK, Ports die du für PoE nutzt musst du dann beachten aber netzwerktechnisch sind auch diese Ports gleichbereichtigt.
Das "Port 2 Thema" bezieht sich ganz sicher wieder auf ein System mit Default Konfig. Wäre dann aber auch etwas sinnfrei, denn da bei den kleineren Systemen die Ports 2-5 gleichberechtigt in einer Bridge zusammengefasst sind wäre es auch wieder egal innerhalb dieser Bridgeports.
2.)
Ja. Managementtechnisch gesehen könnte das Sinn machen, denn über den Port kommt ja dein Managementzugang wenn du ihn z.B. aus einem PoE Switch versorgst. Dieser Port sollte ja dann immer verfügbar sein.
Aber wie gesagt das wäre rein aus kosmetischer Managementsicht und wie du es für dich für richtig hälst. Netztechnisch sind auf einem nackten Router (ohne Default Konfig) alle Ports gleichermaßen geeignet weil sie eben allesamt gleichberechtigt sind.
3.)
Ja natürlich. Das klappt. Jeder dieser Ports kann als DHCP Client arbeiten!
Das konfigurierst du ganz einfach und klickst im Winbox Menü lediglich IP -> DHCP Client und aktivierst die Funktion auf dem Interface deiner Wahl. Im Konfig Fenster wirst du dann auch gleich die IP Zuteilung sehen sofern der Port in einem Netz mit DHCP aktiv ist.
Was wichtig ist in diesem Zusammenhang:
Da das ein Routerport ist muss man bei DHCP zugeteilten Routeradressen immer vorsichtig sein. Routen und Endgeräte verlassen sich drauf das Router IP Adressen fest sind damit die Wegefindung immer sauber funktioniert.
Bei per DHCP basierten Routeradressen solltest du dann immer darauf achten das es ein festes Binding auf die Mac Adresse gibt und der Router immer diese IP vom DHCP Server fest zugewiesen bekommt und sich das nicht ändert mit der DHCP Dynamik.
Wenn du bzw. der DHCP Server das beachtet spricht nichts gegen eine DHCP Vergabe.
Was wichtig ist: Da das ein Routerport ist muss man bei DHCP zugeteilten Routeradressen immer vorsichtig sein. Routen und Endgeräte verlassen sich drauf das Router IP Adressen fest sind.
Bei per DHCP basierten Router adressen solltest du dann immer darauf achten das es ein festes Binding auf die Mac Adresse gibt und der Router immer diese IP fest zugewiesen bekommt und sich das nicht ändert mit der DHCP Dynamik.
Wenn du bzw. der DHCP Server das beachtet spricht nichts gegen eine DHCP Vergabe.
Bei per DHCP basierten Router adressen solltest du dann immer darauf achten das es ein festes Binding auf die Mac Adresse gibt und der Router immer diese IP fest zugewiesen bekommt und sich das nicht ändert mit der DHCP Dynamik.
Wenn du bzw. der DHCP Server das beachtet spricht nichts gegen eine DHCP Vergabe.
Dann lasse ich das besser. Der Hintergrund war ja, dass ich das bei mir zuhause einrichte (da würde der Port die IP 192.168.100.9 bekommen) und den konfigurierten Router dann in das Netz des Pfarrzentrums hänge, wo der Port die IP 10.200.0.2 bekäme).
Nur nebenbei zur Router Adressierung:
Router sollten im Subnetzbereich immer die Adressen ganz oben oder ganz unten haben. Das minimiert Kollisionen mit DHCP Ranges und damit IP Adresschaos bei diesen wichtigen Adressen.
Bei einem klassischen /24er Präfix also entweder .1 oder .254
Wichtig ist bei statischer Vergabe mit diesen Adressen immer zur Sicherheit die konfigurierte DHCP Adressrange zu kontrollieren das die .1 oder .254 sicher aus dem Pool ausgeschlossen sind. Oder auch 2-3 Adressen an den Enden die man ggf. nutzt.
So weiss man aus Management Sicht immer das die ersten und letzten 2-3 Adressen Infrastruktur ONLY sind und damit "Do not touch" sind.
Adressen mittendrin erhöhen immer die Gefahr der Doppelvergabe mit einem DHCP Pool und zeugen meist von einem Admin mit unsauberem IP Adressplan. Oder, worst case, gar keinem...
Router sollten im Subnetzbereich immer die Adressen ganz oben oder ganz unten haben. Das minimiert Kollisionen mit DHCP Ranges und damit IP Adresschaos bei diesen wichtigen Adressen.
Bei einem klassischen /24er Präfix also entweder .1 oder .254
Wichtig ist bei statischer Vergabe mit diesen Adressen immer zur Sicherheit die konfigurierte DHCP Adressrange zu kontrollieren das die .1 oder .254 sicher aus dem Pool ausgeschlossen sind. Oder auch 2-3 Adressen an den Enden die man ggf. nutzt.
So weiss man aus Management Sicht immer das die ersten und letzten 2-3 Adressen Infrastruktur ONLY sind und damit "Do not touch" sind.
Adressen mittendrin erhöhen immer die Gefahr der Doppelvergabe mit einem DHCP Pool und zeugen meist von einem Admin mit unsauberem IP Adressplan. Oder, worst case, gar keinem...
Deine ToDos:
Für den DHCP Server klickst du ins Winbox Menü IP -> DHCP dort auf den großen Button "DHCP Setup". Hier kannst du dann für das jeweilige Interface deiner Wahl menügeführt den DHCP Server mit Range, Gateway, DNS usw. einrichten.
Für den DHCP Server klickst du ins Winbox Menü IP -> DHCP dort auf den großen Button "DHCP Setup". Hier kannst du dann für das jeweilige Interface deiner Wahl menügeführt den DHCP Server mit Range, Gateway, DNS usw. einrichten.
Hier bekomme ich einen Fehler. Erst mal die bisherige Konfiguration
Nun gehe ich also auf DHCP-Setup und gebe ein:
Server-Interface: UnifiGast
Address-Space: 192.168.45.1
Gateway: 192.168.45.1
Adresses to give out: 192.168.45.11-192.168.45.250
Dann erhalte ich die Meldung "Invalid Adress Pool". Ich vermute, dass es mit dem "Adress-Space" zu tun hat, denn die anderen Parameter scheinen mir sinnvoll. Nur was mit Adress-Space hier meint ist, weiß ich nicht. Bei Adressraum (deutsche Übersetzung) hätte ich spontan 192.168.45.1/24 gesagt, aber das kann ich nicht eingeben ...
Nun gehe ich also auf DHCP-Setup und gebe ein:
Reden wir jetzt vom DHCP Server oder vom Client?? Ich denke Server so es sich anhört...?!Dann erhalte ich die Meldung "Invalid Adress Pool".
Bedeutet das du dich da vertippt hast.Bewege dich mit den Cursor Tasten der Vorgabe nur an den Hostbereich und ändere die vorgegebene Hostrange. Es dürfen keine Leerzeichen am Bindestrich sein!
hätte ich spontan 192.168.45.1/24 gesagt
Das wäre ja eine Hostadresse! Sinnvoller und logisch wäre in dem Falle dann das Netzwerk anzugeben mit 192.168.45.0/24Und genau DAS gibt der MT dir doch auch automatisch vor und musst du nur abnicken!!
Wie im Tutorial beschrieben: Du musst das nur der Reihe nach abnicken und einzig nur die Adressrange und den DNS anpassen. Fertisch...
- Entweder lässt du den Eintrag leer, dann gibt der MT den unter IP -> DNS konfigurierten oder via DHCP Client gelernten DNS per DHCP weiter an die Clients.
- Oder du gibst dort die Router IP an dem Interface an und lässt den MT selber als Caching DNS arbeiten. Er beantwortet dann alles lokal und fragt nur wenn er was nicht weiss den unter IP -> DNS konfigurierten oder via DHCP Client gelernten DNS als Forwarder. Wichtig: Dazu muss unter IP -> DNS der Haken bei "accept remote requests" gesetzt sein!
Zitat von @aqui:
Das wäre ja eine Hostadresse! Sinnvoller und logisch wäre in dem Falle dann das Netzwerk anzugeben mit 192.168.45.0/24
Und genau DAS gibt der MT dir doch auch automatisch vor und musst du nur abnicken!!
Das wäre ja eine Hostadresse! Sinnvoller und logisch wäre in dem Falle dann das Netzwerk anzugeben mit 192.168.45.0/24
Und genau DAS gibt der MT dir doch auch automatisch vor und musst du nur abnicken!!
Nein, er gibt mir 192.168.45.1 vor. Wenn ich das in 192.168.45.0/24 ändere, fragt er nach dem Gateway nach einem DHCP-Relay ....
Edit: Der "Fehler" lag bei der Definition der IP-Adressen. Ich habe offenbar falsch gelesen und bei "Network" nicht das Netwerk, sondern die Netzwerkmaske angegeben:
Nach Korrektur dort:
Nachtrag Ich habe jetzt mal mein Notebook als zweiten Rechner an dem Port angeschlossen. Dann wird der Eintrag zwar schwarz, aber es wird keine Adresse ausgegeben. Der Reiter Leases bleibt leer, und das Notebook gibt sich eine APIPA-Adresse ...
... den unter IP -> DNS konfigurierten ...
Kann ich da tatsächlich nur einen eingeben?
Fast überall kann man mindestens zwei eingeben, falls einer mal ausfällt. Was nimmt man denn da am besten? Die FritzBox? Oder die berühmte 8.8.8.8 ?
Und wieder eine Zusatzfrage:
Wie sage ich dem MT, dass er jetzt zur Zeit über meinen Router 192.168.100.1 auf dem Interface Home ins Internet kommt? Ich würde nämlich gerne das RouterOS updaten, und da sagt er (obwohl ich bei DNS jetzt die 8.8.8.8 eingetragen habe) dass er die Adresse nicht auflösen kann ...
Nein, er gibt mir 192.168.45.1 vor
- Welche Firmware Version verwendest du??
- Wenn du unter System --> Routerboard gehst, ist dein Bootloader auf die gleiche Version wie deine Firmware upgedatet??
bei "Network" nicht das Netwerk, sondern die Netzwerkmaske angegeben
OK, dann ist das natürlich klar. Kleine Ursache, große...Das füllt die Winbox übrigens immer automatisch aus. Bei Mikrotik wird in der Regel die Maske immer hinter der Adresse bzw. Netz mit "/xy" angegeben.
Kann ich da tatsächlich nur einen eingeben?
Nein, da kann man natürlich auch mehrere angeben! Es ist ja keine Fritte... 😉Du siehst hinter dem Eingabefenster einen noch oben und unten gerichteten Doppelpfeil. Wenn du auf die untere Hälfte klickst macht sich ein neues, zusätzliches Eingabefenster auf für weitere DNS Serveradressen. Gewusst wie...
Was nimmt man denn da am besten?
Welcher ist denn dein zentraler DNS Server den du im Netz deinen Clients mitgibst? Den trägst du da ein. Wenn das die Fritte ist dann nimmst du diese.⚠️ Beim Gastnetz aufpassen das du als DNS IP auch einen Server angibst der vom Gastnetz auch erreichbar ist. Gastnetze sind prinzipbedingt ja üblicherweise isoliert. Andernfalls scheitert die DNS Auflösung sollte die vergebene DNS IP von Gastclients nicht erreichbar sein!
Die 8.8.8.8 nehmen verantwortungsvolle Netzwerk Admins wie du es ja auch bist, aus guten Gründen niemals! Muss man sicher nichts mehr zu sagen...
Und wieder eine Zusatzfrage: Wie sage ich dem MT, dass er jetzt zur Zeit über meinen Router 192.168.100.1 auf dem Interface Home ins Internet kommt?
Das machst du ganz einfach mit der Default Route!Du gehst unter IP --> Route und trägst dort die Default Route ein:
- Ziel: 0.0.0.0/0
- Gateway: 192.168.100.1
⚠️ Hier wieder ein Achtung!
Auf deinem 192.168.100.1er Router müssen dann auch die Rückrouten definiert sein in die IP Netze am MT aus denen Traffic kommen kann der über ihn geht. (Siehe "Packetreise" im Tutorial]!)
Sind die nicht eingetragen routet sie dein 192.168.100.1er Router über seine Default Route zum Provider und damit ins Nirwana und du schiebst Routing Frust.
Hier an einem Beispiel mit einem Netzwerk:
Welche Firmware Version verwendest du??
Wenn du unter System --> Routerboard gehst, ist dein Bootloader auf die gleiche Version wie deine Firmware upgedatet??
Wenn du unter System --> Routerboard gehst, ist dein Bootloader auf die gleiche Version wie deine Firmware upgedatet??
Kann ich nun gefahrlos ein Firmware-Update anstoßen? Oder habe ich dann genau das Problem, dass der Bootloader nicht mit aktualisiert wird und ich danach unterschiedliche Versionen habe.
Davon abgesehen: Hattest Du die Frage wahrgenommen, warum der DHCP-Server nun trotz der Korrektur im Bereich IP-Adressen keine Adresse ausgibt und in der Liste etwas von Relay steht?
Das war ja zur Zeit das aktuteste Problem ...
Auf deinem 192.168.100.1er Router müssen dann auch die Rückrouten definiert sein in die IP Netze am MT aus denen Traffic kommen kann der über ihn geht. (Siehe "Packetreise" im Tutorial]!)
Sind die nicht eingetragen routet sie dein 192.168.100.1er Router über seine Default Route zum Provider und damit ins Nirwana und du schiebst Routing Frust.Ups ... da enden dann meine Routing-Kenntnisse. Ich dachte, eine Router schickt Antworten immer dahin, von wo aus der die Anfrage bekommen hat.
Da endet dann das Projekt möglicherweise: Das Unifi-LAN (internes Netz) muss ja die Antwort des Cloudkeys über den Mikrotik wieder zurück an das Unifi-Gastnetz routen. Aber hier sind wir ja wieder bei unserem Hauptproblem: Der Cloudkey kann nicht routen
Oder geht das dann über die FritzBox, die ja der Router für das interne UniFi-LAN ist? Also dass die FritzBox sagt, die Pakete für das Gastnetz gehen an {IP-Adresse des Mikrotik im internen LAN}? Denn in der FritzBox kann ich ja Routen definieren ...
Ist der UniFi Gast Port physisch angeschlossen und hat einen Link?
Wenn nein ist das Interface inaktiv und damit ist dann auch der DHCP Server natürlich inaktiv und erscheint rot.
Sollte das Interface aktiv sein müsstest du mal einen Screenshot des Server Setups (IP -> DHCP Server)) und auch einen des Pools (IP -> Pool) posten. Sofern es einen IP Adress Mismatisch zw. Pooladressen und Server gibt wird der natürlich auch rot.
Es ist richtig das der Router die Absender IP "sieht" aber danach sieht er immer zuerst in seine Routing Tabelle um zu wissen wohin er das Paket für das Absender Zielnetz senden muss. Ist das Netz an ihm selber direkt angeschlossen, kein Problem, dann kennt er es und kann es forwarden.
Ist es aber an einem anderen Router angeschlossen wie z.B. oben dann muss er das logischerweise wissen wie er dahin kommt. Dazu gibt es 2 Optionen:
Am obigen Beispiel kannst du das sehr schön sehen.
Die Fritzbox weiss mit ihren 3 statischen Routing Einträgen wie sie die 3 Netze am Mikrotik erreichen kann. Würden diese statischen Routing Einträge fehlen hätte die Fritte nur ihre Default Route die zum Internet Provider zeigt und sie von diesem dynamisch lernt via PPPoE (xDSL) oder DHCP (KabelTV, FTTH). Sie würde dann z.B. dein .45.0er Netz zu deinem Internet Provider senden und damit ins IP Nirwana.
Ganz so schlau wie du dachtest sind die Router also nicht, denn Wegefindung über die IP Netze ist bekanntlich das A&O beim IP Routing. Ein bisschen Admin Pflege bzw. Konfig brauchen sie schon. Bitte lies dir den oben dazu zitierten "Paket Walk" (Paket Reise) im Tutorial nochmal in aller Ruhe durch dann wird dir das schnell klar.
Wenn nein ist das Interface inaktiv und damit ist dann auch der DHCP Server natürlich inaktiv und erscheint rot.
Sollte das Interface aktiv sein müsstest du mal einen Screenshot des Server Setups (IP -> DHCP Server)) und auch einen des Pools (IP -> Pool) posten. Sofern es einen IP Adress Mismatisch zw. Pooladressen und Server gibt wird der natürlich auch rot.
Ups ... da enden dann meine Routing-Kenntnisse.
Deshalb bekommst du hier einmal einen Layer 3 Überblick wie dein Netzwerk aus IP Routing Sicht aussieht. (Falls was nicht stimmen sollte bitte Feedback!)Ich dachte, eine Router schickt Antworten immer dahin, von wo aus der die Anfrage bekommen hat.
Das ist natürlich nur halb gedacht.Es ist richtig das der Router die Absender IP "sieht" aber danach sieht er immer zuerst in seine Routing Tabelle um zu wissen wohin er das Paket für das Absender Zielnetz senden muss. Ist das Netz an ihm selber direkt angeschlossen, kein Problem, dann kennt er es und kann es forwarden.
Ist es aber an einem anderen Router angeschlossen wie z.B. oben dann muss er das logischerweise wissen wie er dahin kommt. Dazu gibt es 2 Optionen:
- Eine statische Route die DU ihm konfigurierst und ihm damit sagst: "Nach X kommst du über Y"
- Beide Router unterhalten sich über ein Routing Protokoll wie RIPv2, OSPF, BGP usw. und tauschen ihre Routen automatisch aus ohne das du etwas konfigurieren musst.
Am obigen Beispiel kannst du das sehr schön sehen.
Die Fritzbox weiss mit ihren 3 statischen Routing Einträgen wie sie die 3 Netze am Mikrotik erreichen kann. Würden diese statischen Routing Einträge fehlen hätte die Fritte nur ihre Default Route die zum Internet Provider zeigt und sie von diesem dynamisch lernt via PPPoE (xDSL) oder DHCP (KabelTV, FTTH). Sie würde dann z.B. dein .45.0er Netz zu deinem Internet Provider senden und damit ins IP Nirwana.
Ganz so schlau wie du dachtest sind die Router also nicht, denn Wegefindung über die IP Netze ist bekanntlich das A&O beim IP Routing. Ein bisschen Admin Pflege bzw. Konfig brauchen sie schon. Bitte lies dir den oben dazu zitierten "Paket Walk" (Paket Reise) im Tutorial nochmal in aller Ruhe durch dann wird dir das schnell klar.
Nochwas Wichtiges...
Deine Mikrotik Firmware ist hoffnungslos veraltet. Leider hast du den o.g. Rat einen Upgrade auszuführen vermutlich überlesen oder schlicht ignoriert.
Zudem hast du einen gravierenden Mismatch zw. Firmware und Bootloader wie du am obigen Screenshot ja selber sehen kannst.
Das solltest du dringenst fixen!!!
Das ist sehr einfach. Die sicherste Methode ist ein lokaler Upgrade sofern dein Mikrotik noch keinen funktionierenden Internet Zugang über den .100.1er Router hat. (Ping Check kannst du über das WinBox Ping Tool machen z.B. auf die 8.8.8.8)
Für das Firmware Update gehst du folgerndemaßen vor:
Deine Mikrotik Firmware ist hoffnungslos veraltet. Leider hast du den o.g. Rat einen Upgrade auszuführen vermutlich überlesen oder schlicht ignoriert.
Zudem hast du einen gravierenden Mismatch zw. Firmware und Bootloader wie du am obigen Screenshot ja selber sehen kannst.
Das solltest du dringenst fixen!!!
Das ist sehr einfach. Die sicherste Methode ist ein lokaler Upgrade sofern dein Mikrotik noch keinen funktionierenden Internet Zugang über den .100.1er Router hat. (Ping Check kannst du über das WinBox Ping Tool machen z.B. auf die 8.8.8.8)
Für das Firmware Update gehst du folgerndemaßen vor:
- Lade dir das MIPSBE Main Package der aktuellen "Stable Version" 7.18.1 von der Mikrotik Download Seite runter. https://mikrotik.com/download
- In der WinBox machst du das Files Fenster auf und lässt die gerade runtergeladene Datei dort einfach per Drag and Drop "reinfallen". Dann startet der Upgrade Prozess was du am Prozentladebalken sehen kannst.
- Ist das fehlerfrei durch sicherst du zuerst deine aktuelle Konfig. Das geht auch übers "File" Menü, dann "Backup" klicken und keine Verschlüsselung. Gib einen Namen für die Sicherung ein und führe sie aus.
- Im Files Menü siehst du nun diese Datei die du wieder ganz einfach per Drag and Drop auf deine Windows Oberfläche kopieren kannst.
- Ist das erledigt führst du unter System -> Reboot einen Reboot (kein! Reset) durch. Das System aktualisiert sich dann automatisch.
- Ist der Mikrotik wieder online in der WinBox gehst du unter System --> Routerboard und klickst dort auch Upgrade um den Bootloader ebenfalls automatisch upzugraden.
- Ist das geschehen fürst du nochmal einen Reboot durch
- Wenn du dann unter System -> Reboot checkst siehst du das System und Bootloader gleich sind.
Deine Mikrotik Firmware ist hoffnungslos veraltet. Leider hast du den o.g. Rat einen Upgrade auszuführen vermutlich überlesen oder schlicht ignoriert.
Weder noch. Was meinst Du, warum ich fragte, wie ich die Kiste ins Internet bringe
Zudem hast du einen gravierenden Mismatch zw. Firmware und Bootloader wie du am obigen Screenshot ja selber sehen kannst.
Kann ich? Wo ist denn die Bootloader-Version zu sehen?
Das ist sehr einfach. Die sicherste Methode ist ein lokaler Upgrade sofern dein Mikrotik noch keinen funktionierenden Internet Zugang über den .100.1er Router hat.
Da der Mikrotik inzwischen einen Internetzugang hat: Soll ich es trotzdem so machen wie von Dir beschrieben, oder gibt es mit Internetzugang eine einfachere Variante?
warum ich fragte, wie ich die Kiste ins Internet bringe
Wie gesagt, ist dafür nicht zwingend. Offline mit einfach Drag and Drop geht auch... Wo ist denn die Bootloader-Version zu sehen?
System --> Routerboard = Current Firmware und Upgrade Firmware müssen gleich sein! Das passiert wenn man dort den "Upgrade" Knopf klickt.oder gibt es mit Internetzugang eine einfachere Variante?
Ja, dann kannst du unter System --> Package gehen und dort einen Versionscheck machen und danch den Upgrade automatisch starten. Das datet dann FW und Bootloader automatisch online up in einem Rutsch.Zitat von @aqui:
Ist der UniFi Gast Port physisch angeschlossen und hat einen Link?
Sollte das Interface aktiv sein müsstest du mal einen Screenshot des Server Setups (IP -> DHCP Server)) und auch einen des Pools (IP -> Pool) posten. Sofern es einen IP Adress Mismatisch zw. Pooladressen und Server gibt wird der natürlich auch rot.
Ist der UniFi Gast Port physisch angeschlossen und hat einen Link?
Sollte das Interface aktiv sein müsstest du mal einen Screenshot des Server Setups (IP -> DHCP Server)) und auch einen des Pools (IP -> Pool) posten. Sofern es einen IP Adress Mismatisch zw. Pooladressen und Server gibt wird der natürlich auch rot.
Beim Erstellen dieses Screenshots habe ich gesehen, dass es vier gleichlautende Pools gibt, vermutlich entstanden bei den diversen Fehlversuchen im Vorfeld:
Macht es Sinn, die Pools 0 bis 2 mal zu löschen?
Deshalb bekommst du hier einmal einen Layer 3 Überblick wie dein Netzwerk aus IP Routing Sicht aussieht. (Falls was nicht stimmen sollte bitte Feedback!)
Wow! Vielen Dank, da musst Du reichlich Arbeit reingesteckt haben. Grundsätzlich ist alles richtig wiedergegeben (die FritzBox rechts hat natürlich die .1 - da lässt AVM im Gastnetz ja nicht viel Spielraum).
Allerdings stimmt das trotzdem nur bedingt, denn der gesamte linke Teil (das 100er-Netz) gibt es ja nur hier bei mir zuhause während der Konfiguration. Nachher im Pfarrzentrum fällt das weg. Gleichzeitig gibt es hier zuhause tatsächlich nur dieses 100er-Netz und die anderen sind nur vorbereitet, aber nicht existent. Ausnahme: Ich habe mein Notebook zum Testen des DHCP-Servers in den Mikrotik-Port gesteckt, an dem nachher das 45er-Netz angeschlossen sein wird.
Noch etwas: Das interne Unifi-LAN hast Du mit Fragezeichen wiedergegeben. Spricht etwas dagegen, den echten IP-Bereich hier zu nennen, oder kann das die Sicherheit des internen Netzes tangieren?
Ganz so schlau wie du dachtest sind die Router also nicht, denn Wegefindung über die IP Netze ist bekanntlich das A&O beim IP Routing.
Ja, jetzt, wo Du das bei mir im Gedächtnis aufgefrischt hast, ist mir das auch wieder klar. Ich habe ja mal einen MCSA gemacht ... ist nur eben gut 20 Jahre her, und was man dann nicht dauernd anwendet, gerät im Gedächtnis irgendwann in den Bereich "Archiv" ...
Ja, dann kannst du unter System --> Package gehen und dort einen Versionscheck machen und danch den Upgrade automatisch starten. Das datet dann FW und Bootloader automatisch online up in einem Rutsch.
Das hatte ich vorhin ja gemacht, aber weiter als bis zur 6.49.18 kommt er nicht:
Die 7er-Version bekomme ich dann wohl nur offline ... das muss dann aber warten, ich muss jetzt erst mal einen Arzttermin wahrnehmen
aber weiter als bis zur 6.49.18 kommt er nicht:
Die 6.49.18 ist die latest Verson des Long Term Releases. Das ist der 6.48er Train. Kannst du auch sehen wenn du auf der MT Download Seite einmal "Router OS v6" anklickst.Du kannst die Kiste aber auch auf der 6.48 LT erstmal belassen. Für deine grundsätzlichen Routing Experimente ist die 7er erstmal nicht zwingend.
Das Major Update musst du in der Tat so wie oben beschrieben lokal machen.
dass es vier gleichlautende Pools gibt, vermutlich entstanden bei den diversen Fehlversuchen im Vorfeld:
Das ist grundsätzlich erstmal nicht falsch, denn der Pool Name ist durch die Nummerierung oben ja eindeutig. Der Inhalt ist weniger relevant.Wichtig ist immer welcher genaue Pool dem Server in seinem Setup zugewiesen ist! Bei dir ist das ja aktuell der dhcp_pool3. Folglich kannst du also die Pools 0 bis 2 löschen, das ist richtig. Solche "Konfig Leichen" aus Versuchen sollte man auch immer strikt löschen um Folgefehler zu vermeiden.
Tip:
Du kannst den Pool unter IP --> Pool auch umbenennen z.B. in pool_unifi_gast um das eindeutig zu halten fürs Management. Der neue Poolname wird dann auch automatisch im DHCP Server Setup übernommen.
Vielen Dank, da musst Du reichlich Arbeit reingesteckt haben.
Immer gerne. Aber mit einer fertigen Vorlage ist das ruckzuck erledigt, keine Sorge.Das interne Unifi-LAN hast Du mit Fragezeichen wiedergegeben.
Der Grund bist du selber! Du hast das in deinem Post am 9.3. (17:47) ausgegraut so das diese Adressierung unbekannt ist. Wenn das ein privates RFC 1918 Allerweltsnetz ist kannst du das natürlich posten, da ist ja dann nix Geheimes dran. Bei öffentlichen IPs ist das natürlich anders.Noch ein paar Anmerkungen zum finalen Design wenn es das 100.0er Netz nicht mehr gibt und alles über das dortige ,179.0er FB Gastnetz soll.
Da die Fritzbox am Gastnetz wieder diverse Einschränkungen und Limits hat solltest du das für ein finales Setup ggf. beachten sofern das zutreffen sollte:
- Das Fritzbox Gastnetz ist ein isoliertes Netz. Das bedeutet auch das statische Routing Einträge NICHT für dieses Netz gelten sondern immer nur für das private LAN Netz!
- Daraus folgt wiederum das das FB Gastnetz keine weiteren IP Netze von Routern die im Gastnetz liegen transparent, also bidirektional, routen kann. Eine weitere Segmentierung hinter dem Gastnetz ist also wegen dieses fehlenden Routing Features der Fritte nicht möglich.
- Eine Segmentierung der Gastnetze mit zentralem Internet Uplink über das Fritz Gastnetz ist aber dennoch problemlos möglich wenn am Anschlussport NAT (IP Adress Translation) auf Seiten des Mikrotik gemacht wird. Mit NAT "sieht" die Fritte die hinter dem MT liegenden IP Netze nicht mehr, da diese alle auf ihre dortige .179.2er IP umgesetzt werden. Die Fritte "denkt" somit alle Absender IPs kommen aus dem Gastnetz. Statische Routen entfallen damit.
- 2 weitere wichtige Punkte die im Endausbau zu klären sind
- 1a. WIE soll der Mikrotik an die bestehende Switch Infrastruktur angekoppelt werden? Als VLAN Trunk sofern es eine VLAN Segmentierung dort gibt.
- 1b. Mit Einzelstrippen aus den jeweiligen VLAN Segmenten. (Umständlich)
- 2. Soll eine Kommunikation der beiden (oder mehreren) IP Netze am Mikrotik erlaubt oder reglementiert sein? Ggf. erfordert eine Reglementierung dann noch entsprechende Firewall Regeln.
Danke für die Antworten. Zunächst gehe ich einmal nur auf den DHCP-Punkt ein, zum einen damir wir den endlich mal abgeräumt bekommen, zum anderen weil ich im Wartezimmer nicht die Ruhe habe, die angesprochenen FritzBox-Einschränkungen und deren Umgehungsmöglichkeiten nachzuvollziehen.
Einen Punkt nur noch dazu zur Vervollständigung Deiner Graphik. Das interne Netz hat die IP 10.224.74.0/24 und die FritzBox als Router darin die IP 10..224.74.81 (frag mich nicht, warum die Firma, die das vor ca. zehn Jahren eingerichtet hat, das so gemacht hat).
Auch nach dem Löschen passiert ... nichts Sobald ich ein Gerät in den Port des Unifi-Gastnetzes stecke, wird der DHCP-Server-Eintrag schwarz wie von Dir vorhergesagt. Es wird nur leider nach wie vor keine IP-Adresse ausgeliefert:
Einen Punkt nur noch dazu zur Vervollständigung Deiner Graphik. Das interne Netz hat die IP 10.224.74.0/24 und die FritzBox als Router darin die IP 10..224.74.81 (frag mich nicht, warum die Firma, die das vor ca. zehn Jahren eingerichtet hat, das so gemacht hat).
Wichtig ist immer welcher genaue Pool dem Server in seinem Setup zugewiesen ist! Bei dir ist das ja aktuell der dhcp_pool3. Folglich kannst du also die Pools 0 bis 2 löschen, das ist richtig. Solche "Konfig Leichen" aus Versuchen sollte man auch immer strikt löschen um Folgefehler zu vermeiden.
Auch nach dem Löschen passiert ... nichts
Sobald ich ein Gerät in den Port des Unifi-Gastnetzes stecke, wird der DHCP-Server-Eintrag schwarz wie von Dir vorhergesagt. Es wird nur leider nach wie vor keine IP-Adresse ausgeliefert:frag mich nicht, warum die Firma, die das vor ca. zehn Jahren eingerichtet hat, das so gemacht hat
Vermutlich keine Fachfirma und die hatten von einer sauberen IP Adressierung ganz sicher keinerlei Schimmer. Die Zeichnung passe ich an.
Es wird nur leider nach wie vor keine IP-Adresse ausgeliefert:
Checke bitte nochmal genau das Mapping des DHCP Servers! Ist der Karteireiter "DHCP" oben! Mit den "Leases" kann man natürlich wenig anfangen wenn schon erst gar keine Leases verteilt werden. 🤪- Ist der korrekte Pool auf den DHCP Server gemappt? Interface IP außerhalb der Pool Range?
- Ist der DHCP Server aufs korrekte Interface gebunden an dem dein Test PC hängt?
- Stimmt das IP Netzwerk unter "Network" mit Pool und Interface Adresse überein? (Tippfehler?!)
Checke bitte nochmal genau das Mapping des DHCP Servers! Ist der Karteireiter "DHCP" oben! Mit den "Leases" kann man natürlich wenig anfangen wenn schon erst gar keine Leases verteilt werden. 🤪
Fehler gefunden! Also nicht die Ursache, aber ich habe mal die DHCP-Server-Konfig gelöscht, dann auch den Adresspool gelöscht und dann den Server neu eingerichtet. Nun funktioniert es. Da waren wohl doch die vier gleichlautenden Adresspools das Problem, auch nachdem ich drei davon gelöscht hatte.
Interessanterweise beginnt er mit der Adressvergabe von hinten, hat meinem Notebook die letzte Adresse des Pools zugewiesen.
Eine Segmentierung der Gastnetze mit zentralem Internet Uplink über das Fritz Gastnetz ist aber dennoch problemlos möglich wenn am Anschlussport NAT (IP Adress Translation) auf Seiten des Mikrotik gemacht wird. Mit NAT "sieht" die Fritte die hinter dem MT liegenden IP Netze nicht mehr, da diese alle auf ihre dortige .179.2er IP umgesetzt werden. Die Fritte "denkt" somit alle Absender IPs kommen aus dem Gastnetz. Statische Routen entfallen damit.
Hm, kann es sein, dass wir heute morgen beim Thema Paketreise aneinander vorbeigeredet haben? Ich weiß, dass man auch ohne NAT routen kann, aber zumindest mir in meinem Kopf war eigentlich völlig klar, dass ich mit "Routen" immer NAT-Routing meine. Und dann, jedenfalls wenn ich Dir jetzt richtig verstanden habe, stimmt meine Aussage "ein Router schickt Antworten immer dahin, von wo aus der die Anfrage bekommen hat" ja doch ... oder?
Gibt es irgendeinen Grund, ohne NAT zu routen?
Und spannende: Wenn Du davon ausgingst, dass ich ohne NAT routen will, dann fürchte ich mal, dass der Eintrag einer Route im Mikrotik alleine noch kein NAT-Routing macht, richtig?
1a. WIE soll der Mikrotik an die bestehende Switch Infrastruktur angekoppelt werden? Als VLAN Trunk sofern es eine VLAN Segmentierung dort gibt.
1b. Mit Einzelstrippen aus den jeweiligen VLAN Segmenten. (Umständlich)
1b. Mit Einzelstrippen aus den jeweiligen VLAN Segmenten. (Umständlich)
Ich dachte tatsächlich an Einzelstrippen (siehe meine Graphik), denn wenn ich auf die Ports am Unifi-Switch, die ich mit den Mikrotik-Ports UnifiLAN und UnifiGast verbinde, jeweils nur ein vLAN gebe, dann ist klar, dass das auch das Default-vLAN ist und Pakete vom Mikrotik zurück zum Unifi-Switch gleich richtig getaggt werden. Dann muss ich mich am Mikrotik gar nicht mehr um vLAN kümmern.
2. Soll eine Kommunikation der beiden (oder mehreren) IP Netze am Mikrotik erlaubt oder reglementiert sein? Ggf. erfordert eine Reglementierung dann noch entsprechende Firewall Regeln.
Das hatte ich in dem Post mit der Geräte-Graphik glaube ich geschrieben: Vom Gastnetz (UnifiGast) ins interne Netz (UnifiLAN) sollen nur Pakete an den Cloudkey geroutet werden:
Muss ich eigentlich noch irgendwo sagen, dass diese Route nur im Netz UnifiGast angewendet werden soll?
Ich weiß, dass man auch ohne NAT routen kann
Das ist auch eigentlich der Normalfall. Das gesamte Internet wird ohne NAT geroutet. Ausnahme sind nur die IPv4 Mobilnetze weil es keine IPv4 Adressen mehr gibt. Dort wird CG-NAT gemacht.Du darfst hier aber keinem Missverständnis zum Opfer fallen!! NAT und Routing haben nichts miteinander zu tun und sind 2 völlig verschiedene Dinge im Netzwerk Umfeld.
Das eine ist nichts anderes als eine Adressumschreibung der Quell- oder Zieladressen im IP Paket auf einem Interface und das andere betrifft die globale Wegefindung in Netzwerken. Du siehst allein schon an der Beschreibung das das 2 völlig unterschiedliche Dinge sind.
NAT ist ja einzig und allein aus der Not geboren das es keine freien IPv4 Adressen mehr gibt. (Siehe zu der Thematik auch hier)
Es ist auch eintig nur ein IPv4 Ding aus diesem Grunde. NAT kennt man bei IPv6 deshalb nicht.
Leider wird das sehr häufig verwechselt und laienhaft in einen Topf geschmissen.
Gibt es irgendeinen Grund, ohne NAT zu routen?
Ja, den gibt es natürlich.Du kannst immer nur in eine Richtung routen. Mit NAT wird ein Link automatisch zur routingtechnischen Einbahnstrasse. In die andere Richtung lässt ein NAT Gateway Sessions nicht durch. Es kann nur das passieren was eine gültige NAT Session aus der anderen Richtung hat. Benötigt man also ein übliches transparentes Routing ist das mit NAT nicht möglich.
Bei einer Gastanwendung oder den meisten Heimnetzen fällt das nicht auf weil Traffic immer nur in eine Richtung geht. Die Gegenrichtung geht nicht.
Im Internet wäre so ein Routing fatal und ein vernetztes, redundantes Internet damit unmöglich. Es würde jetzt aber den Thread sprengen würde man in die Details gehen.
dann fürchte ich mal, dass der Eintrag einer Route im Mikrotik alleine noch kein NAT-Routing macht, richtig?
Das ist richtig! Und...den Begriff "NAT-Routing" gibt es nicht. Er ist auch vollkommen falsch denn es gibt entweder Routing oder NAT! Siehe oben! NAT und Routing = Äpfel und Birnen. - Der Mikrotik braucht also völlig unabhängig vom NAT eine Default Route. Logisch, denn er muss ja wissen wo nicht lokaler Traffic hingeroutet werden muss.
- NAT ist in deinem speziellen Setup aber auch wichtig um die technischen Defizite der Plaste Fritte zu kompensieren. Durch deren eingeschränkte Konfig Optionen kann man über das Gastnetz nicht mehrere IP Netze routen. Das geht nur indem man die Fritte per NAT hinters Licht führt und alle Pakete am Mikrotik so übersetzt das sieht "denkt" sie kommen alle aus ihrem lokalen Gastnetz. Das macht der Mikrotik mit Source NAT indem er alle Absender IP Adressen aus seinen Netzen auf seine IP vom Koppelport zur Fritte umschreibt. Für die Fritte ist das dann alles lokaler Traffic obwohl er in Wahrheit aus unterschiedlichen IP Netzen am Mikrotik kommt. Einfache Logik!
Ich dachte tatsächlich an Einzelstrippen
Kann man natürlich machen aber wie du dir denken kannst ist das natürlich etwas Steinzeit und Neandertal.Da du ja schon eine Segmentierung auf dem Switch in die entsprechenden VLANs hat kann man die Netze auch elegant über eine einzige Strippe mit entsprechendem VLAN Tagging übertragen. Das ist dann die Königsklasse im Netzwerken.
Je nachdem womit du dich wohler fühlst kannst du es so oder so machen.
Dann muss ich mich am Mikrotik gar nicht mehr um vLAN kümmern.
Ja, kann man so sagen aber du bringst dich damit um eine wichtige Lernerfahrung zum Thema VLAN.Beide Lösungen sind aber gangbar.
Vom Gastnetz (UnifiGast) ins interne Netz (UnifiLAN) sollen nur Pakete an den Cloudkey geroutet werden:
Das ist so nicht möglich, denn eine Route, wie du dich erinnerst, ist bei direkt angeschlossenen Netzen nicht nötig. Wozu auch?? Die Netze sind ja am Router selber direkt angeschlossen. Dazu brauch der Router keine Route, denn diese IP Netze kennt er logischerweise immer. Deine eigenen Vornamen vergisst du auch nie...?! Dies musst du mit einer Firewall Regel lösen indem du den Traffic zwischen Gast und LAN dann reglementierst
Die Route oben ist deshalb unsinng und auch falsch. Erstmal hast du bei der Destination fälschlicherweise keine Maske angegeben. (Bei Hostadressen z.B. /32) Zum Zweiten ist dir sicher aufgefallen das Das Zielnetz und das Next Hop Gateway dahin im gleichen IP Netz liegt was natürlich total unlogisch ist. Das sagt einem auch der gesunde IT Verstand.
Also diesen Unsinn schnell wieder löschen.
Das Firewall Regelwerk kommt ganz zum Schluss wenn alles sauber funktioniert. Erst dann macht man die Schotten dicht. So vermeidet man 2 Baustellen zu öffnen sofern man Grundfunktionen wie z.B. dein o.a. DHCP Problem noch troubleshooten muss.
Muss ich eigentlich noch irgendwo sagen, dass diese Route nur im Netz UnifiGast angewendet werden soll?
Nein! Eine Routing Tabelle gilt immer global für den ganzen Router. Ist auch klar, denn IP Netze sind immer einzigartig. Andernfalls würde eine saubere Wegeführung scheitern.
Puh, von Deinen ausführungen habe ich dieses Mal nur die Hälfte verstanden. Routing, Nicht-Routing, NAT ... ich habe gerade das Gefühl, dass ich gar nichts mehr verstehe.
Mag sein, aber ich habe auch nicht ewig Zeit. Hier zuhause kann ich es mangels Masse an Geräten (und Platz) nicht testen, und das Produktivnetz kann ich nicht allzulange lahmlegen. Im Prinzip brauche ich Mittwoch nachmittag einen fertig konfigurierten Mikrotik, weil ich da die Gelegenheit habe, vor Ort aktiv zu werden.
Ich brauche aber meines Erachtens NAT. Ich kann den Cloudkey (soweit ich es verstehe ) nur ansprechen, wenn ich eine IP-Adresse aus dem internen LAN habe, da auch der CloudKey (nur) eine solche hat. Das heißt, die für 10.224.74.85 bestimmten Pakete aus dem Unifi-Gastnet müssen ins interne Unifi-LAN genattet werden.
Ja, kann man so sagen aber du bringst dich damit um eine wichtige Lernerfahrung zum Thema VLAN.
Mag sein, aber ich habe auch nicht ewig Zeit. Hier zuhause kann ich es mangels Masse an Geräten (und Platz) nicht testen, und das Produktivnetz kann ich nicht allzulange lahmlegen. Im Prinzip brauche ich Mittwoch nachmittag einen fertig konfigurierten Mikrotik, weil ich da die Gelegenheit habe, vor Ort aktiv zu werden.
Das ist so nicht möglich, denn eine Route, wie du dich erinnerst, ist bei direkt angeschlossenen Netzen nicht nötig. Wozu auch?? Die Netze sind ja am Router selber direkt angeschlossen. Dazu brauch der Router keine Route, denn diese IP Netze kennt er logischerweise immer.
Ich brauche aber meines Erachtens NAT. Ich kann den Cloudkey (soweit ich es verstehe ) nur ansprechen, wenn ich eine IP-Adresse aus dem internen LAN habe, da auch der CloudKey (nur) eine solche hat. Das heißt, die für 10.224.74.85 bestimmten Pakete aus dem Unifi-Gastnet müssen ins interne Unifi-LAN genattet werden.
Im Unify Gastnetz dürften doch niemals Management Frames irgendwohin gesendet werden. Das würde ein Gastnetz ja ad absurdum führen wenn fremde Gastnutzer solche Frames mit einfach Mitteln mitschneiden könnten.
Was genau sollte auch aus dem Gastnetz kommen. Da sind ja nur Clients und der Mikrotik. Beide haben mit UniFi (glücklicherweise) nix am Hut.
Bei Netzwerkkomponenten kommunizieren die Komponenten letzlich immer nur im Management Netz. Das sowas über ein Gastnetz gesendet wird ist sicher nicht richtig und wäre zudem fatal aus Sicherheits Perspektive.
Aber nungut bei dem UBQT Schrott mit seinen Zwangscontrollern weiss man nie aber es ist schwer vorstellbar das die so einen sicherheitstechnischen Unsinn von einem Admin im Setup verlangen.
Was genau sollte auch aus dem Gastnetz kommen. Da sind ja nur Clients und der Mikrotik. Beide haben mit UniFi (glücklicherweise) nix am Hut.
Bei Netzwerkkomponenten kommunizieren die Komponenten letzlich immer nur im Management Netz. Das sowas über ein Gastnetz gesendet wird ist sicher nicht richtig und wäre zudem fatal aus Sicherheits Perspektive.
Aber nungut bei dem UBQT Schrott mit seinen Zwangscontrollern weiss man nie aber es ist schwer vorstellbar das die so einen sicherheitstechnischen Unsinn von einem Admin im Setup verlangen.
Zitat von @aqui:
Im Unify Gastnetz dürften doch niemals Management Frames irgendwohin gesendet werden. Das würde ein Gastnetz ja ad absurdum führen wenn fremde Gastnutzer solche Frames mit einfach Mitteln mitschneiden könnten.
Im Unify Gastnetz dürften doch niemals Management Frames irgendwohin gesendet werden. Das würde ein Gastnetz ja ad absurdum führen wenn fremde Gastnutzer solche Frames mit einfach Mitteln mitschneiden könnten.
???? Du verwirrst mich gerade total. Ich will doch keine Management-Frames aus dem internen Netz ist Gastnetz senden ...
Was genau sollte auch aus dem Gastnetz kommen. Da sind ja nur Clients und der Mikrotik. Beide haben mit UniFi (glücklicherweise) nix am Hut.
Ich dachte, ich hätte das ganz am Anfang erläutert. Aaaaaalso: Wenn wLAN-Clients sich im Gastnetz anmelden, kommen sie erst mal nicht ins Internet. Sie werden vom AccessPoint erst mal auf den CloudKey umgelenkt, der eine CaptivePortal-Seite anzeigt, in die sie einen Vouchercode eingeben müssen. Erst wenn der Controller auf dem CloudKey sein OK gegeben hat, kommt der Client ins Internet.
Dieser Verkehr muss zwischen Gastnetz und internem Netz passieren können. Aber wenn jemand von einem Client im Gastnetz aus versucht, eine andere Ressource im internen Netz aufzurufen, sollte er das natürlich nicht dürfen ;)
Ich will doch keine Management-Frames aus dem internen Netz ist Gastnetz senden ...
Was willst du denn sonst aus dem Gastnetz senden?? Es gibt doch nichts was Clients an ein UniFi Gerät senden müssen...unverständlich was das sein sollte?Wenn wLAN-Clients sich im Gastnetz anmelden, kommen sie erst mal nicht ins Internet.
Das übliche Captive Portal Prinzip...ein alter Hut!Du begehst hier aber einen fatalen Denkfehler.
Das Captive Portal ist zwar am AP oder Switch aktiv aber das Gerät was das relaisiert sendet doch niemals diese User Authentisierungsdaten über das Gastnetz!
AP oder Switch haben das IP Management Interface über das diese Daten gesendet werden immer im Management VLAN niemals aber im Gastnetz.
Ist das Gastnetz ein WLAN oder LAN?
Dieser Verkehr muss zwischen Gastnetz
Nein, das ist falsch. Das Portal Device (AP oder Switch) sendet diese Daten im Managementnetz was man natürlich aus guten Gründen niemals ins Gastnetz legt.Nicht das die hier noch einen fatalen Security Fehler begehst?!
Nein, das ist falsch. Das Portal Device (AP oder Switch) sendet diese Daten im Managementnetz was man natürlich aus guten Gründen niemals ins Gastnetz legt.
Nicht das die hier noch einen fatalen Security Fehler begehst?!
Nicht das die hier noch einen fatalen Security Fehler begehst?!
Sicher??? Also auch im Bezug auf Unifi? Wenn das so wäre, dann brauchen wir diesen ganzen Mikrotik-Aufwand nicht zu treiben, das ist ja ausschließlich dazu gedacht gewesen, den im internen LAN hängenden CloudKey aus dem Gastnetz erreichbar zu machen.
Aber dann frage ich mich, warum die CaptivePortal-Seite auf den wLAN-Clients nicht angezeigt wird. Ich ging die ganze Zeit davon aus, dass es daran liegt, dass der Cloudkey nicht erreicht wird - oder eben die vom CloudKey ausgelieferte WebSite (Portalseite) den im Gastnetz befindlichen Client nicht erreicht, weil es zwischen den beiden keinen Übergang gibt. Was sonst könnte der Grund sein?
Das ursprüngliche Szenario sieht so aus:
Ich habe noch mal oben gelesen. Ganz am Anfang meinst Du:
Der Anschlussport der APs muss im Trunk Mode konfiguriert sein mit dem PVID 1. Sprich also Traffic vom Default VLAN 1 wird dort UNtagged gesendet aber der Gasttraffic dann mit deinem VLAN 40 Tag in deinem Fall.
Das VLAN 1 darf dort nicht oder fälschlicherweise zum PVID 1 zusätzlich getagged sein, was dann sofort zur Fehlfunktion führt.
Achte also auf die korrekte Konfiguration der AP Ports und der dazu korrespondierenden Switchports.
Das VLAN 1 darf dort nicht oder fälschlicherweise zum PVID 1 zusätzlich getagged sein, was dann sofort zur Fehlfunktion führt.
Achte also auf die korrekte Konfiguration der AP Ports und der dazu korrespondierenden Switchports.
Nur - wie soll ich das beim Unifi-Switch beeinflussen? Das Switchport-Profil "all" sieht so aus:
Ja, das Konzept ist doch bei allen Herstellern immer gleich.
AP und Controller befinden sich immer in einem gemeinsamen Management Netz. Das ist bzw. sollte natürlich immer Kupfer basierend sein und darauf mappt man aus guten Gründen natürlich keine WLAN (M)SSID. Hier findet die gesamte Management Kommunikation statt auch die Authentisierungsdaten für das Captive Portal. AP, Controller Server usw. können sich da problem los pingen und auch erreichen.
Die WLAN SSIDs mappt man dann auf entsprechende VLAN IDs.
Letztlich ist das genau so wie du es oben auch schon gemacht hast. Das Management Netz ist dein Default VLAN 1 und das Gastnetz ist das VLAN 40.
Vom AP kommt also das VLAN 1 UNtagged (PVID 1) und das VLAN 40 getagged. Folglich muss der AP am Switchport ebenso konfiguriert sein: Port Mode = Trunk, PVID 1 und VLAN 40 tagged.
Das Captive Portal wird zwar im VLAN 40 getriggert, da aber die Management IP im VLAN 1 liegt kommuniziert der AP mit dem Controller immer im VLAN 1. Das Gastnetz an sich ist da vollkommen unbeteiligt, was ja auch gewollt ist.
AP und Controller befinden sich immer in einem gemeinsamen Management Netz. Das ist bzw. sollte natürlich immer Kupfer basierend sein und darauf mappt man aus guten Gründen natürlich keine WLAN (M)SSID. Hier findet die gesamte Management Kommunikation statt auch die Authentisierungsdaten für das Captive Portal. AP, Controller Server usw. können sich da problem los pingen und auch erreichen.
Die WLAN SSIDs mappt man dann auf entsprechende VLAN IDs.
Letztlich ist das genau so wie du es oben auch schon gemacht hast. Das Management Netz ist dein Default VLAN 1 und das Gastnetz ist das VLAN 40.
Vom AP kommt also das VLAN 1 UNtagged (PVID 1) und das VLAN 40 getagged. Folglich muss der AP am Switchport ebenso konfiguriert sein: Port Mode = Trunk, PVID 1 und VLAN 40 tagged.
Das Captive Portal wird zwar im VLAN 40 getriggert, da aber die Management IP im VLAN 1 liegt kommuniziert der AP mit dem Controller immer im VLAN 1. Das Gastnetz an sich ist da vollkommen unbeteiligt, was ja auch gewollt ist.
Das Captive Portal wird zwar im VLAN 40 getriggert, da aber die Management IP im VLAN 1 liegt kommuniziert der AP mit dem Controller immer im VLAN 1. Das Gastnetz an sich ist da vollkommen unbeteiligt was ja auch gewollt ist.
Was noch nicht erklärt, warum es nicht funktioniert
(Ich habe oben noch ergänzt)
Was noch nicht erklärt, warum es nicht funktioniert
Das kann viele Gründe haben... Jetzt kann man nur raten- Stelle erstmal sicher das Controller und AP sich managementtechnisch im VLAN 1 erreichen können.
- IP sollten also beide in der VLAN 1 Range haben und dort pingbar sein das ist Grundvoraussetzung das die miteinander reden können.
- Member im Gast VLAN muss der Controller Server mit Sicherheit nicht sein. Für den reicht ganz sicher ein einfacher UNtagged Access Port im VLAN 1 (PVID 1)
- Nur der AP muss im Trunk Mode am Switch angeschlossen sein. PVID 1 damit UNtagged Management Traffic des APs ins VLAN 1 des Controller gewordwardet werden kann. VLAN 40 muss dort tagged anliegen. Logisch, denn der AP sendet allen Traffic vom VLAN 40 mit einem entsprechenden VLAN Tag was die Switchseite auch haben muss um diese Frames ins VLAN 40 forwarden zu können!
Hast du das so umgesetzt?
Jein. Zur Zeit ist der CloudKey (also der Controller-Server) noch ein einem Switchport mit dem Profil "All" angeschlossen:
Den Port könnte ich natürlich auf das Profil "LAN" umschalten, also dass er nur im internen Netz, welches zugleich Management-LAN ist, angebunden ist:
Ich weiß aber nicht, ob das etwas bringen würde. Das native (also ungetaggte) vLAN ist in beiden Fällen die 1 (vom Controller als "Default" bezeichnet).
Ob die Konfiguration "All" dann aber dem entspricht, was Du skizziert hast (Gastnetz-vLAN ist übrigens 47, nicht 40, das war oben vertippt):
Nur der AP muss im Trunk Mode am Switch angeschlossen sein. PVID 1 damit UNtagged Management Traffic des APs ins VLAN 1 des Controller gewordwardet werden kann. VLAN 40 muss dort tagged anliegen. Logisch, denn der AP sendet allen Traffic vom VLAN 40 mit einem entsprechenden VLAN Tag was die Switchseite auch haben muss um diese Frames ins VLAN 40 forwarden zu können!
weiß ich nicht. Ich wüsste aber auch nicht, wie man es anders konfigurieren könnte. Der Controller bietet ja nur diese Möglichkeiten zur vLAN-Konfiguration eines Switchports:
Was da dann unter der Motorhaube draus gemacht wird, weiß ich nicht.
noch ein einem Switchport mit dem Profil "All" angeschlossen:
Wenn, dann sollte man es schon richtig machen. Endgeräte bekommen immer Ports im "Access Mode".auf das Profil "LAN" umschalten, also dass er nur im internen Netz, welches zugleich Management-LAN ist, angebunden ist:
Würde ja Sinn machen....Ob die Konfiguration "All" dann aber dem entspricht
Lässt vermuten das damit der Trunk Mode gemeint ist und alle konfigurierten VLANs tagged da draufliegen. Das machen gerade die Billo Hersteller oft so damit User mit wenig Netz- und VLAN Kenntnissen auch eine Switchkopplung hinbekommen.Für eine saubere VLAN Konfig ist sowas aber immer kontraproduktiv. Reine Accessports für Endgeräte sollten auch immer als Access Ports definiert sein.
Trunk Ports dann entsprechend als Trunks aber nicht im Modus "All" was (vermutlich) dann alle VLANs darüberbringt. Ggf. auch solche die man am anderen Ende überhaupt nicht benötigt. Der gesamte Broad- und Multicast Traffic dieser ungenutzten VLANs landet dann auf diesem Trunk und belastet ihn performancetechnisch unnötigerweise.
Sowas zeugt immer von einer schlechten und unsauberen VLAN Konfig. Also Trunk Mode ja, aber getaggte VLANs dann dort dediziert angeben und keinen "Schrotschuss". Das dient auch der Netzwerk Sicherheit.
Was da dann unter der Motorhaube draus gemacht wird, weiß ich nicht.
Weiss wohl auch nur UniFi. Andere Hersteller machen sowas bedeutend besser und auch alles ohne externe Zwangscontroller die eh von gestern sind.
Das klingt jetzt alles so, als wären wir in einer Sackgasse.
Das ist gerade frustrierend ...
- Der Mikrotik-Ansatz, an dem weit mehrere Tage gewerkelt haben, war für die Katz' weil es gar nicht nötig ist, die CaptivePortal-Anfragen aus dem Gastnetz ins interne Netz zu routen, weil diese Anfragen eh über das Management-LAN laufen.
- Konkrete Fehler in meiner Unifi-Konfiguration siehst Du nicht.
- Weitere Ideen hast Du auch nicht (außer genereller Kritik an Unifi, die aber nicht weiterführt)
Das ist gerade frustrierend ...
Konkrete Fehler in meiner Unifi-Konfiguration siehst Du nicht.
Aus den Screenshots von oben nicht.Allerdings ist das auch recht oberflächlich da...
- man nicht erkennen kann auf welchem Port diese Profile aktiv sind
- man nicht weiss WO du die 3 beteiligten Endgeräte, AP, Controller, PC angeschlossne hast (Portnummer) und welches Profil da werkelt.
Es muss aber grundsätzlich noch etwas am Switchsetup falsch sein, denn wenn du den Controller und den AP als auch die Switch IP im Default VLAN 1 schon nicht pingen kannst hast du ja schon ein Connectivity Problem im L2.
Das solltest du zuallererst mal sicherstellen das ein PC im VLAN 1 sowohl den Switch als auch den AP und den Controller pingen kann, denn alle diese Komponenten liegen ja in einem gemeinsamen LAN Segment.
Zitat von @aqui:
Allerdings ist das auch recht oberflächlich da...
Konkrete Fehler in meiner Unifi-Konfiguration siehst Du nicht.
Aus den Screenshots von oben nicht.Allerdings ist das auch recht oberflächlich da...
- man nicht erkennen kann auf welchem Port diese Profile aktiv sind
- man nicht weiss WO du die 3 beteiligten Endgeräte, AP, Controller, PC angeschlossne hast
Das war eigentlich aus der Zeichnung ersichtlich:
- AP an einem Port mit Profil "All"
- CloudKey an einem Port mit Profil "All" (kann ich morgen vor Ort aber auch mal mit Profil "Lan" testen)
- Ausgang zu FritzBox Port 2 an einem Port mit Profil "Lan"
- Ausgang zu FritzBox Port 4 an einem Port mit Profil "Gastnetz"
Es muss aber grundsätzlich noch etwas am Switchsetup falsch sein, denn wenn du den Controller und den AP als auch die Switch IP im Default VLAN 1 schon nicht pingen kannst hast du ja schon ein Connectivity Problem im L2.
Wer sagt, dass ich die nicht pingen kann? Ich kann sowohl die FritzBox als auch den Cloudkey als auch den Unifi-Switch als auch die Accesspoints (in der Graphik nur einer, real zwei) problemlos pingen ...
Wer sagt, dass ich die nicht pingen kann?
Sorry, das hatte ich dann in den falschen Hals bekommen. 🙈Aber wenn die Connectivity da ist liegt es ja de facto nicht mehr am Netzwerk.
Aber wenn die Connectivity da ist liegt es ja de facto nicht mehr am Netzwerk.
Woran dann? Bist Du sicher, dass auch bei Unifi die Anfrage eines wLAN-Clients am Captive-Portal, die Auslieferung der CaptivePortal-Portalseite (HTML) und der Authentifizierungsprozess nach Voucher-Eingabe über das Management-LAN läuft?
Oder muss der Client eben doch mit dem ControllerServer (Cloudkey) kommunizieren können, der in einem ganz anderen IP-Segment liegt (Client z.B. 192.168.179.11/24, Cloudkey 10.224.74.85/24)? Es ist ja nicht nur das vLAN, sondern eben auch der IP-Bereich ...
Bist Du sicher
Nein, mitnichten. Normal, wenn man mit UniFi so gar nichts am Hut hat!Das müsste final einer der anderen UniFi Knechte hier beurteilen. Ich hatte mich lediglich an das Standard Prozedere gehalten wie es 98% der anderen WLAN Hersteller umsetzen.
Dort kommuniziert ein Gastclient niemals aktiv mit der Netzwerkinfrastruktur. Genau DAS will man in einem Gastnetz ja auch gar nicht.
Das CP rennt meistens auf dem AP dieser wickelt dann das gesamte Nutzer Authentisierungshandling mit dem Controller ab. Da der AP ja nur eine IP im Management Netzwerk hat kann er ja auch schon physisch nur allein mit dieser IP kommunizieren.
Das Gastnetzwerk hat ja keinerlei aktive IP Adresse auf der Netzwerk Infrastruktur lediglich nur auf der Fritte. Wie sollte da dann überhaupt eine Kommunikation aus dem Gastnetz möglich sein?! Ohne IP keine Kommunikation...einfache Logik!
Nein, mitnichten.
Na dann schlage ich vor (wenn sich hier nicht ein Unifi-Experte zu Wort meldet), wir versuchen meinen Ansatz mit dem NAT über Mikrotik mit dem Ziel, dass Geräte im Gastnetz den Controller im internen Netz ansprechen (und von dort auch eine Antwort erhalten) können. Im Zweifelsfall werden wir davon beide schlauer ...
Um NAT noch einmal besser zu verstehen: Du sagst, Routing und NAT haben miteinander nichts zu tun. Routing ohne NAT gibt es. Gibt es auch NAT ohne Routing? Wenn NAT das Paket in einen anderen Adressbereich "schickt", muss es dann nicht automatisch auch in ein anderes Netzwerksegment?
Gibt es auch NAT ohne Routing?
Ja, sicher und das ist der Nortmalfall. Wie oben schon mehrfach gesagt sind das doch immer 2 verschiedene Paar Schuhe.NAT ist eine reine Adress Translation. Sprich an einem Interface übersetzt ein Gerät Absende- oder Empfangs IP Adressen in einem IP Paket. NAT "schickt" nie IP Pakete in andere Segmente, das kann und macht einzig und allein nur ein Router. Nicht mehr und nicht weniger. Ob der dann NAT an einem seiner Interfaces machen soll oder nicht ist Konfigurationssache. NAT kann auch ein Server usw. machen.
IP Adressübersetzung hat per se ja rein gar nichts mit IP Routing also der Wegefindung von IP Paketen in einem Netz zu tun.
Webbrowsing hat ja direkt auch nichts mit Email zu tun. Äpfel und Birnen...
Ok, aber ich halte es dann trotzdem für sinnvoll (zumindest um der Erkenntnis willen), das mit dem Mikrotik mit NAT und Routing einmal auszuprobieren. Bei einem DSL-Router werden NAT und Routing ja immer zusammen konfiguriert - wie funktioniert das bei Mikrotik - da muss ich es offenbar separat konfigurieren? Woher weiß der dann am Ende, dass die Route X und das NAT X zusammengehören?
das mit dem Mikrotik mit NAT und Routing einmal auszuprobieren
Klar, warum nicht. Versuch macht bekanntlich klug und man lernt was dabei! Eine Konfig liegt dir ja vor... Bei einem DSL-Router werden NAT und Routing ja immer zusammen konfiguriert
Ja und nein!Wenn du den reinen einfachen Consumer Bereich betrachtest mit dem Billo Plaste Routern wie Fritte, Speedport & Co. dann ja. Das Endverbrauchern ohne Fachkenntnisse aufzubürden wäre so als wenn du bei der Lufthansa den Flugnavi konfigurieren müsstest.
Im kommerziellen Bereich bei Routern und Firewalls sieht das aber ganz anders aus. Da dort deutlich vielschichtigere Konfigs vorkommen gibt es das dort nicht. Vermutlich hast du bis dato nur einfache Consumer Hardware gesehen und dann fehlt etwas der Horizont.
wie funktioniert das bei Mikrotik - da muss ich es offenbar separat konfigurieren?
Auch hier ja und nein!Wenn du den Mikrotik werksresettest kannst du ja frei wählen ob du die default Konfig laden willst oder nicht.
Bei der default Konfig hast du immer eine Fritzbox ähnliche Grundkonfiguration:
- ether1 ist immer der WAN Port. Arbeitet im DHCP Client Mode um sich eine IP zu ziehen und hier ist Firewall und auch NAT aktiv. Analog zu einer Fritte, Speedport & Co.
- ether 2 bis 5 sind über eine Bridge zusammengefasst als lokales LAN mit aktivem DHCP Server dort. Also auch analog wie Fritte, Speedport & Co.
Verneinst du die default Konfig startet der Mikrotik als unkonfigurierter Router dem man dann entsprechend IP Adressierung, NAT, Firewall und Routing nach den eigenen Vorgaben konfigurieren muss wie es im kommerziellen Bereich auch üblich ist.
Du hast dort also als Anwender dort die freie Wahl.
Woher weiß der dann am Ende, dass die Route X und das NAT X zusammengehören?
Das definiert man alles in der Firewall. NAT wird üblicherweise im Firewall Setup definiert. Sieh dir die dir vorliegende Konfig mit NAT einmal an im IP -> Firewall Karteireiter und dort unter NAT. Dort ist das alles in einer einzigen Regel definiert.
