20 KiB
RouterOS-Capabilities für hAP ax² (BF-Netz, RouterOS 7.23.1)
Recherche-Report — Stand 2026-06-15 Ziel: Verstehen, was RouterOS 7.23 für ein Prosumer-Multi-VLAN-Heimnetz kann, und empfehlen, was bei knappem CPU/RAM passt.
0. Hardware-Fakten (live von ap1 abgefragt)
| Eigenschaft | Wert | Bedeutung |
|---|---|---|
| Modell | hAP ax² (C52iG-5HaxD2HaxD) |
ARM64, IPQ-6000 |
| RouterOS | 7.23.1 stable (build 2026-06-02) | aktuell |
| CPU | ARM64, 864 MHz, 4 Cores | solide, aber kein Kraftpaket |
| RAM | 1 GB total — im Leerlauf ~681 MB frei | der echte Engpass |
| Flash | 128 MB total, ~94 MB frei | begrenzt → Container nur klein |
| Lizenz | Level 4 | reicht für alles hier Relevante |
Konsequenz für alle Empfehlungen: RAM ist die harte Grenze. Jeder Container kostet 10–100 MB. Mehr als 2–3 kleine Container parallel + WLAN + Routing wird eng. CPU-intensive Dinge (TLS-Terminierung, Web-Proxy unter Last, VPN-Durchsatz) treffen die 4 schwachen Cores. Faustregel: native Pakete bevorzugen, Container sparsam, alles Schwere auf die NAS auslagern.
Installierte vs. verfügbare Pakete (live): Aktiv sind nur routeros + wifi-qcom. Als available/disabled liegen bereits auf dem Gerät: container, calea, dude, iot (MQTT/Modbus), gps (LoRa), openflow, user-manager, zerotier, wireless, tr069-client, ups, rose-storage. Aktivieren = /system package enable … + Reboot, kein Download nötig.
1. Gateway-/Router-HA via VRRP
Userfrage: „Was, wenn ap1 ausfällt?"
(a) Was es macht: VRRP (Virtual Router Redundancy Protocol) lässt zwei hAP eine gemeinsame virtuelle Gateway-IP je VLAN teilen. Der Master mit höherer Priority hält die virtuelle IP; fällt er aus, übernimmt der Backup binnen ~3× advertisement-interval (Default 1 s → ~3 s Umschaltung). Clients behalten dasselbe Default-Gateway.
(b) Verfügbarkeit: Nativ in RouterOS (/interface/vrrp), kein Paket. VRRPv3 für IPv4+IPv6.
(c) Nutzen: Echtes Gateway-Failover je VLAN. Mit zwei VRRP-Instanzen pro VLAN (kreuzweise Master/Backup) sogar Load-Sharing möglich.
(d) CPU/RAM-Kosten: Vernachlässigbar (nur kleine Multicast-Advertisements). Kein Problem.
(e) Empfehlung: VIELLEICHT (für VLANs mit echtem HA-Bedarf, z. B. MAIN 10 / INFRA 20). VRRP-Last ist gratis, aber der Betriebsaufwand für echtes Failover ist hoch — siehe Gotchas. Für ein Heimnetz reicht oft simpler: zweiter hAP als kalter Ersatz + Config-Backup.
Config-Skizze (kreuzweises Master/Backup, pro VLAN)
# ap1 — Master für VLAN10, Backup für VLAN20
/interface vrrp add name=vrrp-vlan10 interface=vlan10 vrid=10 priority=200 version=3
/interface vrrp add name=vrrp-vlan20 interface=vlan20 vrid=20 priority=100 version=3
/ip address add address=10.40.41.1/24 interface=vrrp-vlan10 ;# virtuelle GW-IP
/ip address add address=10.40.42.1/24 interface=vrrp-vlan20
# ap2 — gespiegelt: Backup für VLAN10, Master für VLAN20
/interface vrrp add name=vrrp-vlan10 interface=vlan10 vrid=10 priority=100 version=3
/interface vrrp add name=vrrp-vlan20 interface=vlan20 vrid=20 priority=200 version=3
/ip address add address=10.40.41.1/24 interface=vrrp-vlan10
/ip address add address=10.40.42.1/24 interface=vrrp-vlan20
Gotchas (wichtig!)
- RouterOS kann NICHT „Owner" sein → die virtuelle IP darf nicht gleichzeitig die echte Interface-IP eines Routers sein. Jeder Router braucht zusätzlich eine eigene reale IP pro VLAN (z. B. .2 / .3), die virtuelle (.1) liegt auf dem VRRP-Interface.
- Die VRRP-IP muss auf Master UND Backup identisch konfiguriert sein, sonst werden Advertisements verworfen.
- VRRP umfasst nur die IP/Routing-Ebene — NICHT den Rest. DHCP-Server, Firewall-/NAT-Regeln, DNS, Routen müssen auf beiden Routern identisch gepflegt werden, sonst ist nach Failover „Gateway up, aber Internet/DHCP tot". Das ist der eigentliche Betriebsaufwand. Tipp: DHCP-Server auf beiden mit identischem Pool/Gateway, oder DHCP-Failover-Lease-Sync vermeiden (Split-Pool).
- Advertisement-interval nicht unter 1 s → sonst Flapping.
- WAN-Seite: Failover des Internet-Uplinks ist ein separates Problem (siehe §10 Multi-WAN), VRRP löst nur das LAN-Gateway.
- Quellen: VRRP (help.mikrotik.com), VRRP Configuration Examples
2. WLAN-Mesh vs. Wired Backhaul
Ausgangslage: Beide APs haben verdrahtete Trunk-Uplinks (alle VLANs).
(a)/(c) Optionen:
| Ansatz | Was | Für uns |
|---|---|---|
| Wired backhaul + CAPsMAN | Beide APs per Kabel am Trunk, gleicher Bridge/VLAN; zentrale WLAN-Config via CAPsMAN-Controller; APs broadcasten dieselben SSIDs mit 802.11r/k/v-Roaming | Empfohlen. Voller Speed, kein Funk-Tribut, nahtloses Roaming |
| WLAN-Mesh (WDS / wireless station-backhaul) | Ein AP funkt zum anderen als Backhaul | Nur sinnvoll, wenn kein Kabel da wäre — ist es aber. Halbiert Funk-Durchsatz, mehr Latenz |
(b) Verfügbarkeit: CAPsMAN ist nativ im wifi-qcom-Paket (ROS7 „WiFi", /interface/wifi/capsman). Ein hAP kann gleichzeitig CAP und CAPsMAN-Controller sein (kein extra Gerät nötig). 802.11r/k/v Roaming + Steering nativ.
(d) CPU/RAM: CAPsMAN-Controller für 2 APs ist trivial-leicht. WLAN-Mesh kostet mehr (zwei Radios busy).
(e) Empfehlung: WIRED BACKHAUL + CAPsMAN nutzen, Mesh WEGLASSEN. Kabel ist da → keinen Funk-Backhaul-Nachteil einkaufen.
Loop-Risiko über Router/LAN — wichtig
Wenn beide APs mit allen VLAN-Trunks am selben L2-Netz hängen und zusätzlich die WLAN-Bridges dieselben Broadcast-Domains überbrücken, kann ein L2-Loop entstehen (Trunk-A ↔ Switch ↔ Trunk-B ↔ über AP-Bridge zurück). Gegenmittel:
- RSTP/MSTP auf den Bridges aktiv lassen (
protocol-mode=rstp) — fängt versehentliche Loops ab. - Sauberes Bridge-VLAN-Filtering; nur der Trunk-Port ist Tagged-Member, kein Doppelpfad.
- Kein gleichzeitiges WDS/Mesh, während Wired-Backhaul aktiv ist — das ist der klassische Loop-Erzeuger (zwei parallele Pfade zwischen denselben APs). Genau deshalb: entweder/oder, nicht beides.
- Quellen: WiFi / CAPsMAN, Forum: mesh with wifi ax
3. Access-Control / Identity (RADIUS, 802.1X, EAP-TLS, dyn. VLAN)
(a) Was es macht: WPA2/WPA3-Enterprise (802.1X) authentifiziert jeden User/jedes Gerät einzeln gegen einen RADIUS-Server — statt eines geteilten PSK. EAP-TLS = Client-Zertifikat pro User/Gerät (kein Passwort). Der RADIUS kann pro Auth eine dynamische VLAN-Zuweisung zurückgeben (Tunnel-Type=VLAN, Tunnel-Medium-Type=802, Tunnel-Private-Group-ID=) → Gerät landet automatisch im richtigen VLAN, egal an welcher SSID/welchem Port.
(b) Verfügbarkeit auf 7.23:
- User-Manager v5 = eingebauter RADIUS-Server (Paket
user-manager, liegt bereits available auf dem Gerät). Kann EAP-TLS, EAP-TTLS, PEAP. Offizielles Howto: „Enterprise wireless security with User Manager v5". - WiFi-Interfaces:
authentication-types=wpa2-eap,wpa3-eapnativ. - Dot1X (Paket-frei, nativ) für wired 802.1X an Switch-Ports mit dynamischer VLAN-Zuweisung — ABER: dyn. VLAN im Switch-Chip nur auf Geräten mit HW-VLAN-Filtering; nicht auf SMIPS. Der hAP ax² ist kein SMIPS, dyn. VLAN am Port ist hier grundsätzlich möglich — in der Praxis am Heim-Switch aber eher Spielerei.
LDAP-Backend (User hat openldap-Container): User-Manager v5 spricht KEIN LDAP. Er hat eine eigene lokale User-DB. Will man die openldap als Wahrheitsquelle, führt der Weg über FreeRADIUS (mit ldap-Modul) — das läuft nicht sinnvoll als 90-MB-Container auf dem hAP, sondern auf der NAS.
(c) Nutzen: Pro-Gerät-Identität, Zertifikats-Login (kein WLAN-Passwort-Teilen), automatische VLAN-Einsortierung (IoT→30, Gäste→90 etc.). Stark für ein segmentiertes Netz.
(d) CPU/RAM: User-Manager-Paket ist klein (~344 KB Code), die Last entsteht bei EAP-Handshakes (TLS-Krypto). Für ein Heimnetz mit Dutzenden Geräten ist das auf dem hAP vertretbar, aber RAM-Budget im Auge behalten.
(e) Empfehlung:
- RADIUS-Server: FreeRADIUS auf der NAS = beste Option (LDAP-Anbindung an openldap, robust, kein hAP-RAM-Verbrauch, überlebt AP-Reboots). hAP-WLAN zeigt nur auf die NAS-RADIUS-IP. → NUTZEN (NAS).
- User-Manager v5 auf dem Router = VIELLEICHT, als einfache/standalone Alternative ohne LDAP, wenn man keine NAS-Abhängigkeit will. Pragmatisch und in 1 h aufgesetzt, aber Userverwaltung getrennt von openldap.
- EAP-TLS pro Gerät: NUTZEN für stationäre/eigene Geräte, aber Zertifikats-Rollout (CRL, Enrollment) ist Pflege-Aufwand → für Gäste/fremde Geräte lieber PEAP (User+Passwort) oder simpler WPA2/3-PSK je VLAN-SSID.
- Einfachste administrierbare Option für daheim: pro VLAN eine eigene SSID mit eigenem WPA3-PSK. Enterprise/802.1X nur dort, wo Pro-Gerät-Identität wirklich gebraucht wird.
- Quellen: Enterprise wireless security w/ User Manager v5, User Manager, Dot1X, multiduplikator/mikrotik_EAP (GitHub, EAP-TLS+CRL+WPA3)
4. Schlagwortliste (Schnellbewertung)
| Thema | Was | Verfügbar 7.23 | Nutzen / CPU-RAM | Empfehlung |
|---|---|---|---|---|
| RoMON | L2-Management-Overlay (Router ohne IP per MAC erreichen) | Nativ | Quasi gratis | NUTZEN — bequemes Management beider APs auch ohne IP, Lifesaver bei Fehlkonfig |
| IPv6 (intern) | SLAAC/DHCPv6, ND, Firewall | Nativ | Gering | NUTZEN — IPv6-Firewall nicht vergessen (Default offen!) |
| IPv6 (extern, 3 Standorte) | DHCPv6-PD (Prefix Delegation), pro Standort /56 o. /60 → Sub-Prefixe je VLAN | Nativ (/ipv6 dhcp-client … pool, /ipv6 pool) |
Gering | NUTZEN, falls ISP IPv6+PD liefert. Pro Standort eigener Präfix; FritzBoxen FM/BF/DW als CPE können PD weiterreichen — Topologie klären |
| LoRa | LoRaWAN-Gateway-Funktion | Paket gps/lora — aber hAP ax² hat KEINE LoRa-Hardware |
– | WEGLASSEN — kein Funkmodul vorhanden |
| MQTT | IoT-Paket: MQTT-Publish aus Scripts/Scheduler | Paket iot (available) |
Klein | VIELLEICHT — nett für „Router meldet Status an HA", aber HA/NAS macht das besser. Optional |
| SNMP | Monitoring-Agent (CPU, RAM, Traffic, IF) | Nativ | Gering | NUTZEN — Basis fürs Monitoring (siehe icinga). Read-only Community + FW-Regel |
| Email settings | SMTP-Versand aus Scripts (/tool e-mail) |
Nativ | Gering | NUTZEN — Alerts (Netwatch, Failover) per Mail |
| NTP server | Zeit-Server fürs LAN | Nativ | Gering | VIELLEICHT — als interner NTP für IoT/MGMT-VLAN sinnvoll; sonst NTP-Client reicht |
| ZeroTier | P2P-Mesh-VPN | Paket zerotier (ARM, available) |
Spürbar: bis ~60 % CPU bei Last, RAM-Footprint | WEGLASSEN/VIELLEICHT — funktioniert, aber CPU-hungrig auf dem hAP. Für Remote-Zugriff lieber Back-to-Home/WireGuard (§unten) |
| Cloudflare One / WARP | CF Zero Trust Tunnel | Kein natives Paket; nur als cloudflared-Container |
Container-RAM + CPU; macvlan-Konflikte (siehe DNS-Projekt-Notizen) | WEGLASSEN auf dem Router — CF-ZT gehört auf NAS/dedizierten Host, nicht auf den RAM-knappen AP |
| Load-Balancing / Failover (Multi-WAN) | PCC + recursive routing / Netwatch | Nativ | Gering–mittel | NUTZEN bei >1 WAN — siehe §10 |
| OpenFlow | SDN-Controller-Steuerung | Paket openflow (available) |
– | WEGLASSEN — kein SDN-Controller im Heimnetz, sinnlos |
| User-Manager | siehe §3 | Paket (available) | Klein–mittel | VIELLEICHT — RADIUS standalone ohne LDAP |
| CALEA | Lawful-Intercept (behördl. Mitschnitt) | Paket calea (available) |
– | WEGLASSEN — reines Compliance-Feature, irrelevant |
| icinga / check_routeros (Monitoring) | Icinga/Nagios-Plugin via API/SNMP | Extern (auf Monitoring-Host) | 0 am Router | NUTZEN — DinoTools/monitoring-check_routeros gegen SNMP/API; CPU/RAM/IF/Temp/WLAN |
| spectral-scan | Funk-Spektrum-Analyse (Störer-Suche) | Nativ im WiFi-Tool (/interface/wifi spectral-scan) |
Kurzzeitig, on-demand | NUTZEN (ad-hoc) — super zur Kanalwahl/Störer-Diagnose, läuft nur bei Bedarf |
Quellen u. a.: ZeroTier, SNMP, RoMON, check_routeros (GitHub), Load Balancing
5. Reverse Proxy — Erwartung „nein" muss korrigiert werden
Bisherige Erwartung: RouterOS hat keinen Reverse Proxy. → Stimmt für ROS ≤ 7.21, aber NICHT mehr für 7.22+.
- RouterOS hatte lange nur einen Forward/Transparent-Web-Proxy (
/ip proxy, deprecated, Caching) — das ist KEIN Reverse Proxy. - Neu seit 7.22: nativer Reverse Proxy unter
/ip/reverse-proxy. Kann: HTTPS-Terminierung mit ACME/Let's Encrypt, SNI-basiertes Routing mehrerer Hostnames auf interne IPv4-Backends:Port, setztX-Forwarded-For/-Proto. Da die APs auf 7.23.1 laufen, ist das vorhanden.
Kann es nginx-proxy-manager ersetzen? Für simple Fälle ja, aber nicht voll:
- ❌ Kein WebSocket, kein gRPC, keine Sticky Sessions, kein WAF, kein Auth-Layer, keine Log/Header-Manipulation, nur IPv4-Backends.
- ⚠️ TLS läuft auf der Router-CPU → auf hAP/hEX kann Last die CPU auf 100 % treiben.
(e) Empfehlung: WEGLASSEN als NPM-Ersatz auf dem hAP. NGINX Proxy Manager auf der NAS behalten (WebSocket/Backend-Vielfalt/RAM). Den nativen Reverse-Proxy höchstens für 1–2 triviale interne HTTPS-Dienste nutzen, wenn man die NAS gerade nicht einbinden will. Wichtigste Korrektur: „RouterOS hat keinen Reverse Proxy" ist seit 7.22 falsch — es hat einen, nur einen schlanken.
6. mDNS-Repeater (7.16+) + Container-Reflector — bestätigt
- Bestätigt: Seit 7.16 ist ein mDNS-Repeater nativ eingebaut:
/ip/dns/set mdns-repeat-ifaces=bridge,vlan-iot,vlan-main. Relayed mDNS (.local, AirPlay/Chromecast/Discovery, HomeKit-Bonjour) zwischen ausgewählten VLANs — genau das, was man fürs IoT/MAIN-Cross-Discovery braucht. Kostet quasi nichts. → NUTZEN. - Container-Reflector (forum: „Reflector — cross-VLAN casting mDNS+SSDP+DIAL", <10 MB RAM): nötig nur, wenn man zusätzlich SSDP/DIAL (DLNA, manche Smart-TVs) reflektieren muss, was der native mDNS-Repeater NICHT abdeckt. → VIELLEICHT, nur wenn SSDP-Geräte zicken; sonst spart man sich den Container.
- Quellen: mikrotikonlineclub v7.16, Reflector-Container (Forum), mag1024/mikrotik-docker-mdns-repeater
7–10 hier zusammengefasst: 5 nicht-offensichtliche Features für ein CPU/RAM-knappes Setup
Diese geben viel Nutzen pro Byte RAM — alle nativ, kein Container, vernachlässigbare Last:
- Netwatch (
/tool netwatch) — pingt Hosts/Gateways, triggert Scripts. Damit baut man WAN-Failover, Service-Watchdogs und Mail-Alerts ohne Zusatzsoftware. Herzstück eines schlanken HA-Setups. NUTZEN. - Scheduler + Scripts (
/system scheduler,/system script) — Auto-Backups (/export+ Mail), nächtliche Cron-Jobs, Reaktion auf Events. Ersetzt viele „Ich-bräuchte-dafür-einen-Container"-Wünsche. NUTZEN. - DoH — DNS over HTTPS (
/ip/dns set use-doh-server=… verify-doh-cert=yes) — verschlüsselter Upstream-DNS direkt am Router, plus statische DNS-/FWD-Einträge. Passt zur bestehenden DNS-Infra (AdGuard/CF). Geringe Last. NUTZEN/VIELLEICHT (je nach DNS-Architektur — ihr filtert ohnehin via CF/AdGuard). - Back-to-Home VPN (ROS 7.12+, ARM64 ✓) — WireGuard-basierter Fernzugriff per MikroTik-App/QR, NULL Server-Config, funktioniert hinter CGNAT/NAT. WireGuard ist der CPU-effizienteste VPN-Typ (~24 % CPU @ 1000 conns in Vergleichstests, vs. ZeroTier ~62 %). → NUTZEN statt ZeroTier für Remote-Zugriff auf BF. Sehr geringer Footprint.
- Graphing + SNMP → externes Monitoring (icinga/Grafana auf NAS) — der Router liefert nur Zahlen (gratis), die Auswertung/Speicherung läuft extern. Vermeidet
dude/Container-Monitoring auf dem RAM-knappen Gerät. NUTZEN. (calea/dudelokal → WEGLASSEN.)
Bonus: /tool/graphing (eingebaute RRD-Graphen) ist leichtgewichtig für schnellen Blick ohne externes System.
Quellen: Back To Home, WireGuard, Failover (WAN Backup)
10. Multi-WAN / Load-Balancing & Failover (Detail)
(a) Mehrere Internet-Uplinks bündeln (Load-Balance via PCC = Per-Connection-Classifier) oder als Backup (Failover via Routen-distance + check-gateway + Netwatch + recursive routing).
(b) Alles nativ, kein Paket.
(c) Relevant nur, wenn ein Standort >1 WAN hat (z. B. DSL + LTE). Am BF mit FritzBox als einzigem Uplink → erst relevant, wenn zweiter Uplink dazukommt.
(d) Gering bis mittel (PCC-Mangle pro Verbindung). Auf dem hAP unkritisch bei Heim-Bandbreiten.
(e) Empfehlung: NUTZEN, sobald ein zweiter Uplink existiert — sonst PARKEN. Failover (Netwatch + recursive route) ist simpler und robuster als PCC-Load-Balance; für daheim meist die bessere Wahl.
Quellen: Load Balancing, Failover (WAN Backup), vishnunuk/mikrotik-dual-wan-loadbalance-failover (GitHub)
Gesamt-Empfehlungsmatrix (TL;DR)
| Kategorie | Empfehlung |
|---|---|
| Sofort nutzen (nativ, ~0 RAM) | RoMON · Netwatch · Scheduler/Scripts · SNMP · Email-Alerts · mDNS-Repeater (7.16+) · spectral-scan (ad-hoc) · IPv6 intern · Wired-Backhaul + CAPsMAN (802.11r/k/v) · Back-to-Home/WireGuard für Remote |
| Vielleicht / situativ | VRRP-Gateway-HA (nur MAIN/INFRA, hoher Pflegeaufwand) · User-Manager v5 als Standalone-RADIUS · EAP-TLS für eigene Geräte · IPv6-PD extern (falls ISP) · NTP-Server · MQTT · Multi-WAN (sobald 2. Uplink) · Reflector-Container (nur bei SSDP/DLNA) · DoH |
| Auf die NAS auslagern | FreeRADIUS (+LDAP/openldap) · NGINX Proxy Manager · icinga/Grafana-Monitoring · Cloudflare One/WARP (cloudflared) |
| Weglassen | LoRa (keine HW) · OpenFlow · CALEA · ZeroTier (CPU-hungrig → WireGuard nehmen) · dude lokal · nativer Reverse-Proxy als NPM-Ersatz |
Drei zentrale Korrekturen/Erkenntnisse:
- Reverse Proxy: RouterOS 7.22+ HAT einen nativen Reverse-Proxy (
/ip/reverse-proxy, ACME/HTTP-2, SNI) — die Annahme „nein" ist überholt. Ersetzt NPM aber NICHT (kein WS/gRPC, nur IPv4, TLS auf Router-CPU). - „Was wenn ap1 ausfällt?": VRRP löst Gateway-Failover technisch elegant und gratis, aber echtes HA verlangt identische DHCP/Firewall/NAT-Pflege auf beiden Geräten — das ist der Haken, nicht die VRRP-Last.
- RAM ist König: Bei 1 GB gilt „nativ vor Container, NAS vor Router". RADIUS, Reverse-Proxy, CF-Tunnel, Monitoring gehören auf die NAS; der hAP macht Routing/WLAN/VRRP/Netwatch.