MikroTik als Home‑Lab‑Router: VLANs, Firewalling und sichere Netzsegmentierung

Ein Home Lab ist der ideale Ort, um Technologien zu testen, neue Setups zu üben und Automatisierung zu bauen. Wer jedoch alles in ein flaches Netz kippt, riskiert Ärger: IoT-Devices, Testcontainer und private Endgeräte beeinflussen sich gegenseitig, Angriffsflächen addieren sich und Debugging wird mühsam. MikroTik‑Router mit RouterOS sind im Home‑Lab‑Umfeld beliebt, weil sie VLANs, Firewalling und VPNs flexibel vereinen – zu moderaten Kosten. Dieser Leitfaden bündelt erprobte Prinzipien für eine sichere Netzsegmentierung zu Hause mit Fokus auf Developer‑Praxis in Deutschland. Er erklärt Konzepte, typische Fallstricke und einen sicheren Rollout – ohne unsichere Copy‑Paste‑Blöcke.

Hinweis zu Quellen: Für technische Grundlagen verweisen wir auf die offizielle RouterOS‑Doku, z. B. zu VLANs, Bridge VLAN Filtering und Inter‑VLAN‑Routing (MikroTik VLAN‑Doku) sowie zu Firewall, Packet Flow und Connection Tracking (Firewall und QoS). Allgemeine Router‑Sicherheitsprinzipien lassen sich ergänzend an Empfehlungen des BSI spiegeln (Wegweiser Heimnetz).

Warum MikroTik fürs Home Lab?

RouterOS bietet auf einem Gerät: VLAN‑Trunks, Bridge‑VLAN‑Filtering, stateful Firewall, NAT, DNS/DHCP‑Server, mehrere VPN‑Optionen sowie gute Management‑Tools. Für Home‑Labs ist das attraktiv, weil damit Netztrennung, sichere Fernzugriffe und reproduzierbare Testszenarien in einem konsistenten Stack möglich sind. Wichtig ist, MikroTik nicht wie einen „besseren Heimrouter“ zu behandeln, sondern wie ein flexibles, aber sensibles Netzwerkbetriebssystem – Änderungen sollten geplant, getestet und rückrollbar sein.

Architekturüberblick: Ziele einer Netzsegmentierung zu Hause

Ziel ist nicht „möglichst viele VLANs“, sondern nachvollziehbare Sicherheitsgrenzen und klare Verantwortlichkeiten. Ein praxistaugliches Zonenmodell trennt:

• Clients: Laptops/Desktops und Mobilegeräte für Arbeit/Privat.
• Server/Services: Homelab‑Server, Proxmox/ESXi‑Hosts, NAS, Container‑Infrastruktur.
• IoT/Haustechnik: Kameras, Sensoren, Smart‑Home‑Hubs, TVs.
• Gäste: isoliertes Netz ohne Zugriff auf interne Ressourcen.
• Management: dediziertes, restriktives Netz für Router/Switches, Out‑of‑Band‑Konsolen.

Sicherheitsziele je Zone sind unterschiedlich: IoT braucht oft Internetzugriff, aber keinen East‑West‑Zugriff; Management dagegen braucht Reachability aus definierten Admin‑Quellen, aber kein generelles Internet. Diese Sicherheitsziele bestimmen Firewall‑Policies und DNS/DHCP‑Design.

VLAN‑Grundlagen auf MikroTik

VLANs sind Layer‑2‑Segmente gemäß IEEE 802.1Q. Getaggte Trunks transportieren mehrere VLANs über eine physische Verbindung; Access‑Ports sind untagged und ordnen Frames einem VLAN zu. In RouterOS ist Bridge VLAN Filtering der empfohlene Weg, um VLAN‑Mitgliedschaften an Switch‑Ports sauber zu definieren. Für Inter‑VLAN‑Routing stellt der Router IP‑Interfaces pro VLAN bereit (Gateway‑IPs), die anschließend durch Firewall‑Regeln kontrolliert werden. Wichtige Punkte:

• VLAN‑IDs: 0, 1 und 4095 sind reserviert bzw. haben Sonderfälle – im Zweifel vermeiden (siehe MikroTik‑VLAN‑Doku). 1 als „Default‑VLAN“ führt oft zu historischen Altlasten; wählen Sie explizite IDs.
• Tagged vs. untagged: Uplinks zu Switches und APs sind Trunks (tagged). Endgeräte‑Ports sind meist untagged und genau einem VLAN zugeordnet.
• MTU: Mit 802.1Q kommen 4 Byte Overhead hinzu. Planen Sie End‑to‑End‑MTU konsistent, besonders wenn VLANs mit VPNs oder PPPoE kombiniert werden; Fragmentierung und PMTU‑Probleme sind typische Fehlerquellen (siehe MikroTik‑VLAN‑Doku: MTU‑Hinweise).
• Bridge VLAN Filtering: Vermeidet Layer‑2‑Leakage. Definieren Sie je VLAN, welche Ports tagged/untagged und welche Ports Trunk sind. Das ist die Basis für „kein Traffic dort, wo er nicht hingehört“.

Weiterführend: MikroTik VLAN‑Doku

Firewall‑Prinzipien im Home Lab

RouterOS nutzt Connection Tracking, um stateful Regeln zu ermöglichen. Das ist entscheidend für „deny by default“ und gezielte „allow“‑Ausnahmen. Für konsistente Regeln hilft es, den Packet‑Flow von RouterOS zu verstehen (Chains: input, forward, output; Interaktion mit Bridge/Routing). Grundsätze:

• Zwei Perspektiven: Edge‑Firewall (WAN‑Kante) und East‑West‑Filtering (zwischen VLANs). Beide sind nötig. Nur eine „starke Edge‑Firewall“ reicht nicht, wenn interne Segmente beliebig aufeinander zugreifen.
• Standardpolicy: Blocken Sie im forward‑Pfad grundsätzlich Traffic zwischen VLANs, erlauben Sie nur spezifische Flows (z. B. „Clients → HTTP/HTTPS → Server‑VLAN:Reverse‑Proxy“). Für IoT meist nur „IoT → DNS/NTP → Internet“ und ggf. „→ spezifische lokale Gateways“.
• Input‑Pfad: Schützt den Router selbst. Managementzugriffe nur aus dem Management‑VLAN und ggf. über VPN erlauben. Keine Admin‑Ports aus dem Internet exponieren.
• ICMP: Nicht pauschal droppen. Selektiv erlaubte ICMP‑Typen helfen beim Betrieb (MTU‑Discovery, Reachability).
• NAT/UPnP/NAT‑PMP: Home‑Labs profitieren selten von automatischem Port‑Forwarding. Wenn unvermeidbar, eng begrenzen. Prüfen Sie Alternativen über VPNs.

Vertiefung: Firewall und QoS, insbesondere „Packet Flow in RouterOS“ und „Connection Tracking“.

Netzwerkdienste: IP‑Plan, DHCP, DNS und Managementzugriff

Ein sauberer IP‑Plan je VLAN erleichtert Betrieb und Fehleranalyse. Beispielhafte Leitplanken:

• IP‑Plan: Pro VLAN ein eigenes Subnetz mit dokumentierten Gateways, DHCP‑Pools und statischen Reservierungen für Dienste. Management‑Netz bewusst klein halten und streng kontrollieren.
• DHCP: Je VLAN ein eigener Scope mit sinnvollen Lease‑Zeiten. Kritische Infrastruktur (Router, Switches, Hypervisor, NAS) statisch oder via DHCP‑Reservation.
• DNS: Für Home‑Labs bewährt sich ein lokaler Resolver/Forwarder mit Split‑DNS für interne Hostnamen. Minimieren Sie Leaks von internen Domains ins öffentliche DNS. Vermeiden Sie DoH/DoT‑Mischungen, die Troubleshooting erschweren – wenn genutzt, dann konsistent konzipieren.
• Managementzugriff: Separates Management‑VLAN, Admin‑Hosts mit restriktiven Regeln. Router‑Dienste (WinBox, WebFig, SSH, API) nur auf Management‑Interfaces binden und im input‑Pfad selektiv erlauben. Rollen statt Shared‑Admin: getrennte Accounts, nachvollziehbare Rechte.

Grundlagen zur Erstauslieferung und Absicherung: First Time Configuration

Fernzugriff und VPN

Für Zugriff von unterwegs sind VPNs robuster als exponierte Admin‑Ports oder breit geöffnete Port‑Forwards.

• Topologie: Client‑to‑Site für Admins (Laptop/Smartphone → Router). Site‑to‑Site optional, wenn das Lab an einen zweiten Standort gekoppelt wird (z. B. Remote‑Backup).
• Protokollwahl: MikroTik unterstützt u. a. WireGuard und IPsec. WireGuard ist für viele Home‑Lab‑Szenarien wegen einfacher Schlüsselverwaltung und Performance attraktiv; IPsec bleibt relevant für Site‑to‑Site und Kompatibilität.
• Zonen‑Policies: VPN‑Clients landen vorzugsweise in einem dedizierten VPN‑VLAN/Subnetz. Aus diesem Netz werden Management‑ und gewünschte Service‑Ziele gezielt erlaubt, nicht pauschal „alle VLANs“.
• MFA und Gerätesicherheit: Mindestens Gerätesperre und starke Schlüssel. Wenn möglich, zweite Faktoren über Identity‑Provider oder Gerätebindung realisieren.

Weiterführend: VPN‑Abschnitt in der RouterOS‑Doku (Navigationspunkt „Virtual Private Networks“ von der Firewall/QoS‑Seite aus erreichbar).

Logging, Monitoring und Backups

• Syslog/Remote‑Log: Kritische Events (Firewall‑Drops an sensiblen Chains, VPN‑An/Abmeldungen, Konfig‑Änderungen) an ein internes Log‑Ziel oder einen zentralen Syslog‑Host senden. Rotationen auf dem Router sind begrenzt – Remote‑Logs sichern forensische Spuren.
• Metriken/Monitoring: Basis‑Checks für Interface‑Errors, Temperatur, CPU/RAM, DHCP‑Lease‑Fehler, VPN‑Status. Auch ein kleines Home‑Lab profitiert von „Known Good“-Baselines.
• Konfigurationssicherung: Export/Backup regelmäßig. Nach jedem größeren Schritt eine Version mit sprechendem Namen ablegen. Backups offline sichern. Für Wiederherstellung testen: „Restore“ auf Ersatzgerät oder virtuelle Testinstanz üben. Siehe „Configuration Management“ in der First‑Time‑Doku.

Risikominimierter Rollout: nicht aussperren

Konfigurationsarbeit am aktiven Router birgt das Risiko, sich selbst auszusperren. Vorgehensprinzipien:

• Staging: Änderungen schrittweise, erst auf unkritischen Ports/VLANs validieren, dann auf Trunks ausrollen.
• Zeitfenster: Planen Sie Wartungsfenster, in denen ein Reboot oder Rückbau akzeptabel ist.
• Out‑of‑Band: Wenn möglich, serielle Konsole oder dedizierter Management‑Port außerhalb der betroffenen VLANs verwenden.
• Safe‑Mode: RouterOS bietet einen Safe‑Mode, der Änderungen automatisch verwirft, wenn die Session abreißt. Für riskante Schritte aktivieren.
• Rücksetzplan: Dokumentierter Plan mit: „Wie komme ich per MAC/WinBox, seriell oder Netinstall zurück?“ Halten Sie eine bekannte, funktionierende Basiskonfiguration bereit.

Erstinitialisierung und Zugriffswege beschreibt die First Time Configuration. Das BSI empfiehlt für Heimrouter grundlegend, Remote‑Zugänge zu minimieren und Gäste‑Netze zu trennen – auch für Home‑Labs sinnvoll (BSI‑Wegweiser).

Typische Regelmuster ohne Copy‑Paste

Ohne konkrete Befehle lassen sich Muster klar beschreiben:

• Deny by default: forward‑Chain standardmäßig blocken; nur benötigte Flows zwischen VLANs erlauben. Beispiel: Clients → HTTPS → Reverse‑Proxy im Server‑VLAN; Backup‑Server → NFS → NAS.
• Input‑Härtung: Management‑Dienste nur aus Management‑VLAN und optional via VPN. Keine Admin‑Services am WAN. Ping/ICMP dosiert erlauben.
• DNS/DHCP‑Pfad: DNS‑Queries aus IoT/Gäste gezielt nur an Ihren Resolver; keine direkten externen Resolver, wenn nicht nötig. DHCP‑Relay/Server pro VLAN eindeutig.
• Ost‑West‑Filterung: IoT kann oft gar nicht in andere VLANs, nur ins Internet und zu expliziten lokalen Endpunkten (z. B. ein MQTT‑Broker im Server‑VLAN).
• Logging: „Drop with log“ sparsam einsetzen – nur an sensiblen Stellen; sonst füllen Log‑Stürme den Speicher.

Technische Hintergründe: Packet Flow in RouterOS und Connection Tracking.

Trade‑offs und häufige Fehler

• Komplexität: Jedes weitere VLAN, jede Sonderregel erhöht Betriebsaufwand. Starten Sie klein (z. B. Clients, Server, IoT, Gäste, Management) und erweitern Sie erst, wenn der Bedarf klar ist.
• MTU‑Fallen: VLANs + PPPoE + VPN können effektiv die MTU deutlich drücken. Planen und testen Sie PMTU und Jumbo‑Frames konsistent End‑to‑End. Bei Problemen: zuerst Fragmentierung und ICMP‑Reachability prüfen (siehe Hinweise in der MikroTik‑VLAN‑Doku).
• „Default‑VLAN“‑Trägheit: Unreflektiert VLAN 1 weiterzuverwenden erschwert späteres Härten. Besser früh auf saubere, explizite VLAN‑IDs und Bridge‑Filtering setzen.
• UPnP bequem, aber riskant: Für Spielkonsolen oder P2P mag es kurzfristig helfen, öffnet aber Einfallstore. Im Home‑Lab bevorzugt gezielte Port‑Forwards oder VPN.
• Unsaubere Managementgrenzen: Admin‑Dienste „auf allen Interfaces“ binden ist bequem, aber brandgefährlich. Bindung und input‑Regeln strikt halten.

Fazit und empfohlener Umsetzungsfahrplan

MikroTik eignet sich hervorragend als Herzstück eines Home‑Lab‑Netzes – wenn Sie mit einem klaren Zonenmodell starten, die Firewall bewusst zwischen Edge und East‑West denken und Management/VPN sauber trennen. Ein pragmatischer Start:

1. Netzwerkplan erstellen: VLANs und IP‑Plan skizzieren, betriebliche Ziele je Zone definieren.
2. Bridge VLAN Filtering und Trunks implementieren, Access‑Ports pro Segment zuweisen.
3. Gateways/IPs je VLAN setzen, Inter‑VLAN‑Routing aktiv – aber durch „deny by default“ blocken.
4. Allow‑Regeln gezielt ergänzen, begleitend Logging an neuralgischen Stellen.
5. DHCP/DNS pro Zone, Management‑Dienste auf Management‑Interfaces binden.
6. VPN für Fernzugriff einrichten und in ein dediziertes Subnetz routen.
7. Backups, Remote‑Syslog, einfache Metriken aktivieren; Safe‑Mode/Rollback testen.

Für die technische Tiefe und konkrete Optionen nutzen Sie die offizielle Dokumentation, insbesondere zu VLANs und Firewall/Packet‑Flow/Connection‑Tracking. Für einen sicheren Start und Rücksetzpfade lohnt der Blick in die First Time Configuration. Ergänzend geben die BSI‑Empfehlungen Orientierung für grundlegende Router‑Härtung im Heimbereich. So entsteht Schritt für Schritt ein robustes Home‑Lab mit klaren Grenzen – ohne Copy‑Paste‑Risiken und mit sauberer Betriebsbasis.