| img | ||
| README.md | ||
IPfire-Router/-Firewall auf Lenovo ThinkCentre m720q
Homelab-Eigenbau eines 2,5-GbE-Routers/-Firewalls auf einem gebrauchten m720q Tiny mit nachgerüsteter 4-Port-Multi-Gig-NIC und IPfire, inklusive der Grenzen, an die das Projekt gestoßen ist.
Status / Ergebnis: Als kabelgebundener 2,5-GbE-Router/Firewall lief das System (Zonen RED und GREEN). Der geplante WLAN-Access-Point (BLUE) scheiterte an der WLAN-Hardware (siehe Troubleshooting); das Netzwerk managt heute wieder eine FRITZ!Box (4×1 GbE), der m720q läuft inzwischen als Heimserver für andere Projekte. Dieses Repo dokumentiert Aufbau, Entscheidungen und Stolpersteine so, wie sie tatsächlich aufgetreten sind.
Motivation / Warum selbst bauen
Der ehrlichste Grund zuerst: Ich hatte einfach Lust drauf. Selbst bauen, experimentieren und dabei etwas lernen: das war die eigentliche Triebfeder. Der Rest sind gute Argumente, die dazukamen.
Handfester Ausgangspunkt war der Wunsch nach 2,5-GbE im Heimnetz zu einem vernünftigen Preis. Eine FRITZ!Box mit 2,5-GbE-Ports war die Vergleichsmarke. Der Eigenbau sollte darunter bleiben und gleichzeitig mehr Kontrolle und Erweiterbarkeit bieten.
Ein zunächst ins Auge gefasster fertiger Mini-PC fiel raus, weil sich in ihm keine PCIe-Karte nachrüsten ließ. Genau diese Erweiterbarkeit war die Bedingung: nur mit freiem PCIe-Steckplatz lässt sich eine Multi-Port-NIC einsetzen. Der m720q Tiny bietet über einen PCIe-Riser exakt diese Option, bei kleinem Formfaktor und geringem Stromverbrauch.
Alle nötigen Teile lagen zusammen bei rund 172 €. Die Rechnung:
| Teil | Auswahl | Preis |
|---|---|---|
| Mini-PC | Lenovo ThinkCentre m720q Tiny (gebraucht) | 104,55 € |
| Netzwerkkarte | GLOTRENDS LE8245F, 4-Port PCIe | 26,99 € |
| PCIe-Riser | Lenovo 01AJ940 (Tiny-Riser) | 17,28 € |
| SSD | 256 GB NVMe (SanDisk SSD Plus) | 23,64 € |
| Summe | 172,46 € |
Hardware
| Komponente | Details |
|---|---|
| Plattform | Lenovo ThinkCentre m720q Tiny |
| CPU | Intel Core i3-8100T (4C/4T, 35-W-T-Serie) |
| Arbeitsspeicher | 8 GB DDR4-2666 (1 Riegel, zweiter Slot bewusst frei gelassen) |
| Datenträger | 256 GB M.2-NVMe (SanDisk SSD Plus); vorhandene 2,5"-SATA-SSD ausgebaut |
| Zusatz-NIC | GLOTRENDS LE8245F: 4× RJ45, 4× Realtek RTL8125BG, PCIe 2.0 x2 |
| PCIe-Anbindung | Lenovo Tiny-Riser 01AJ940 (BA7H70 Rev. 1.2) |
| Onboard-NIC | Realtek RTL8111/8168, 1 GbE |
| WLAN (intern) | Intel Dual Band Wireless-AC 3165 (M.2, 1×1 802.11ac), ausgebaut |
| WLAN (extern) | EDUP AX3000 WiFi 6 USB-Stick mit 2 externen Antennen; als AP gescheitert (s. u.) |
| Leistungsaufnahme | ≈ 15 W im Idle; unter Last deutlich höher |
Die NIC im Detail: warum „4×2,5G" praktisch 2×2,5G + 2×1G bedeutet
Die LE8245F wird als „Quad Port 2.5G" beworben und hat auch vier RJ45-Buchsen mit je einem eigenen RTL8125BG (2,5-GbE-fähig). Der Flaschenhals ist die Anbindung: Die Karte hängt mit PCIe 2.0 x2 am System (der Steckkontakt ist physisch als x4 ausgeführt), grob ~6,4 Gbit/s nutzbarer Durchsatz. Vier Ports à 2,5 Gbit/s würden aber 10 Gbit/s verlangen.
Ergebnis: Nur zwei Ports laufen gleichzeitig mit vollen 2,5 Gbit/s, die anderen beiden bleiben bei Gigabit. Die ehrliche Beschreibung lautet also 2× 2,5 GbE + 2× 1 GbE. Für einen Router mit einer Handvoll Zonen ist das völlig ausreichend. Man sollte es nur wissen, bevor man „Quad 2,5G" auf dem Karton liest.
Kleine Pointe am Rande: In der Verkaufsanzeige stand ursprünglich „2× 1G und 2× 2,5G". Als die Karte ankam und die beiliegende Herstellerkarte „Quad Port 2.5G" versprach, habe ich mich über das vermeintliche Upgrade gefreut. Rechnet man die PCIe-Anbindung mit ein, war die Anzeige am Ende näher an der Realität als das Marketing auf der Karte.
Einbau in den Tiny
Der m720q hat auf dem Board selbst keinen PCIe-Steckplatz. Erst der Lenovo-Tiny-Riser stellt im rechten Winkel zum Board überhaupt einen PCIe-Slot bereit. Darauf sitzt die 4-Port-Karte; die vier RJ45-Ports zeigen dann nach hinten aus dem Gehäuse. Zusammen mit dem Onboard-Port stehen dem System fünf Netzwerk-Anschlüsse zur Verfügung.
Zwischenlösung: erster Aufbau auf einem alten Tower
Kleine Randgeschichte: Beim Bestellen hatte ich nicht auf den Versandort geachtet, prompt kam ein Teil erst aus China, und die Wartezeit zog sich entsprechend. Statt Däumchen zu drehen, habe ich in der Zwischenzeit einen alten Tower entstaubt und dort schon mal die Firewall-Software ausprobiert.
Phase 1, ganz ohne die neue Karte: Der Aufbau war bewusst improvisiert. Das OS lief vom USB-Stick (es war keine SSD zum Basteln frei), das Netzwerk hing am Onboard-Port plus einem USB-2,5-GbE-Dongle. Das reichte, um Installation und Bedienung der Software überhaupt erst kennenzulernen.
Phase 2, mit der 4-Port-Karte: Sobald die NIC da war, kam sie zuerst in den Tower, denn der hat im Gegensatz zum Tiny normale PCIe-Slots und brauchte keinen Riser. Genau auf diesem Aufbau fiel dann auch die Entscheidung zwischen OPNsense und IPfire (siehe nächster Abschnitt). Die Screenshots der NIC-Erkennung und der Weboberfläche stammen aus dieser Testphase, nicht schon vom fertigen m720q.
Kernentscheidung: die Firewall-Distribution, die man auch bedienen kann
Ursprünglich sollte OPNsense (FreeBSD-Basis) laufen, und lief zunächst auch. Der Haken lag bei der 2,5-GbE-Karte, und zwar als klassisches Henne-Ei-Problem: Um die Realtek-RTL8125-Chips ans Laufen zu bekommen, hätte ich die passenden Treiber nachladen müssen, wofür ich eine Internetverbindung gebraucht hätte, die ohne ebendiese Treiber nicht zustande kam. Ein Deadlock zwischen Netzwerk und Treiber, aus dem man nur mit Umwegen wieder herauskommt.
Erschwerend kam hinzu, dass ich im Umgang mit BSD nicht geübt bin. Schon der
gewohnte Schnellcheck „sieht das System die Karte überhaupt?" ließ sich nicht mal
eben mit lspci erledigen. Aus dem gedachten „ach, das machst du mal eben kurz"
wurden an dem Abend dann über zwei Stunden, der Homelab-Klassiker.
Statt mich in eine fremde Umgebung zu verbeißen, bin ich auf IPfire (Linux-Basis) gewechselt. Dort erkannte der Kernel die Karten ohne Nacharbeit, und die Diagnose lief mit vertrauten Werkzeugen. Im IPfire-Netzmenü tauchten sofort alle vier RTL8125-Ports plus der Onboard-Port auf.
Die Lehre ist dabei nicht „FreeBSD schlecht, Linux gut" (BSD finde ich nicht schlecht, ich mag Linux schlicht lieber), sondern vielmehr: Es zählt, wie gut ich die Plattform selbst betreiben und debuggen kann. Genau darum fiel die Wahl an dieser Stelle auf das Linux-basierte IPfire.
Netz-Architektur
IPfire ordnet Netze in Farbzonen. In Betrieb waren RED und GREEN (kabelgebunden). Die WLAN-Zone (BLUE) wurde versucht, aber verworfen.
Internet
│
│ RED (WAN): Adresse vom vorgelagerten Uplink
│
┌────────┴──────────────────────────────┐
│ IPfire auf m720q Tiny (i3-8100T) │
│ NIC nutzbar: 2×2,5G + 2×1G + 1×1G onb.│
└───┬───────────────────┬────────────────┘
│ GREEN ┊ BLUE
│ 192.0.2.0/24 ┊ WLAN-AP versucht, verworfen
│ (Beispiel) ┊ (AP-Durchsatz < 200 Mbit/s)
┌─────┴──────┐
│ LAN-Geräte │ WLAN heute: FRITZ!Box (4×1 GbE)
└────────────┘
Alle in Diagramm und Screenshots gezeigten Adressen sind Doku-Adressen nach RFC 5737 (
192.0.2.0/24,198.51.100.0/24) und entsprechen nicht der real verwendeten Adressierung.
Einrichtung / Setup
- Hardware vorbereiten: gebrauchten m720q geprüft; die vorhandene 2,5"-SATA-SSD ausgebaut (Platzkonflikt mit dem Riser) und durch eine M.2-NVMe ersetzt.
- Riser + NIC: Tiny-PCIe-Riser (01AJ940) montiert und die 4-Port-NIC darauf eingesetzt.
- OS-Test: die Firewall zunächst auf einem alten Tower ausprobiert (siehe Abschnitt „Zwischenlösung"), bevor die Zielhardware komplett war.
- OPNsense zu IPfire: nach der Treiber-/Diagnose-Sackgasse unter OPNsense auf IPfire gewechselt und vom USB-Stick installiert.
- Zonen zuweisen: im IPfire-Installer („Extended Network Menu") die NICs den Farbzonen zuordnen (GREEN, RED).
- Web-GUI: Verwaltung über
https://<host>:444. RED verbindet sich, GREEN ist aktiv.
Softwarestand laut Oberfläche: IPfire 2.29 (x86_64), Core-Update 196.
Inbetriebnahme- & Prüf-Befehle
IPfire wird über Weboberfläche und pakfire gepflegt. Nützliche Handgriffe beim
Aufbau und zur Kontrolle:
# Paketliste aktualisieren und Core/Add-ons einspielen
pakfire update
pakfire upgrade
# Link-Status/-Speed eines Ports prüfen, wegen der PCIe-Grenze wichtig:
# zeigt, welche Ports real 2500 vs. 1000 Mb/s aushandeln
ethtool green0
ip -c addr
# Kernel-Sicht auf die Realtek-NICs
dmesg | grep -i r8169
Grundsatz im Normalbetrieb: ein ruhiger Log ist der beste Log.
Troubleshooting
Aus echten Stolpersteinen dieses Baus:
| Symptom | Ursache | Vorgehen |
|---|---|---|
| 2,5-GbE-Karte unter OPNsense nicht nutzbar | Henne-Ei: Treiber-Nachinstallation braucht Internet, Internet braucht den Treiber; dazu wenig Routine mit BSD-Diagnose (kein gewohntes lspci) |
Wechsel auf IPfire (Linux): Kernel bringt die Unterstützung mit, Diagnose mit vertrauten Tools |
| PCIe-Karte lässt sich im Tiny gar nicht stecken | m720q hat keinen PCIe-Slot auf dem Board | Lenovo-Tiny-Riser (01AJ940) nachrüsten, stellt rechtwinklig den PCIe-Slot bereit |
| Nach NIC-Einbau kein Platz für 2,5"-SATA-SSD | Riser/Karte belegen den Bauraum der SATA-Bucht | Umzug auf M.2-NVMe |
| Nicht alle vier Ports schaffen 2,5 Gbit/s gleichzeitig | PCIe-2.0-x2-Anbindung (~6,4 Gbit/s) < 4×2,5 Gbit/s (10 Gbit/s) | Einplanen: 2 Ports @2,5G + 2 Ports @1G; Portbelegung entsprechend wählen |
| EDUP AX3000 (USB) liefert als AP dauerhaft nur < 200 Mbit/s, trotz WiFi-6-Specs | nicht abschließend geklärt; vermutlich Grenzen von USB-WLAN-Chipsatz/Treiber im AP-Modus | ausgiebige Recherche ohne Durchbruch, daher WLAN-AP verworfen, FRITZ!Box übernimmt das WLAN |
Der WLAN-Versuch, an dem das Projekt endete
Die im m720q verbaute Intel Dual Band Wireless-AC 3165 ist eine typische Client-Karte: 802.11ac im 1×1-Ausbau, also eine Antennenkette und entsprechend begrenzter Durchsatz. Für den Betrieb als Access Point war sie damit von vornherein die falsche Hardware, weshalb Modul und interne Antenne rausflogen.
Ersatz sollte ein EDUP AX3000 WiFi 6 USB-Stick mit zwei externen Antennen werden. Auf dem Papier passte das: WiFi 6, Dual Band, AX3000. In der Praxis kam über den Access-Point-Betrieb aber nie mehr als rund 200 Mbit/s heraus, egal wie viel ich gelesen und probiert habe. An dieser Stelle habe ich das Thema begraben.
Der Verdacht bleibt beim Zusammenspiel aus USB-WLAN-Chipsatz, Treiber und AP-Modus: Viele dieser Sticks sind primär als Client gedacht, und was im AP-Betrieb tatsächlich an Modi, Kanalbreiten und Raten unterstützt wird, steht selten auf der Verpackung. Nachgemessen oder final belegt habe ich das nicht.
Voraussetzungen / Merkzettel
- Tiny mit Riser-Option (m720q / M920q / P330 Tiny o. ä.), damit eine PCIe-Karte überhaupt passt.
- Lenovo-Tiny-Riser für die PCIe-Karte einplanen. Ohne ihn hat der Tiny keinen PCIe-Slot.
- NIC vor dem Kauf ganz prüfen: nicht nur Portanzahl und -Label, sondern Chipsatz (Treiberlage zur Zielsoftware) und PCIe-Anbindung (nutzbare Bandbreite über alle Ports).
- Consumer-WLAN-Hardware taugt nur bedingt als Access Point. Interne Client-Karten wie die Intel AC 3165 (1×1) sind dafür ungeeignet, und auch bei USB-Sticks sagt die beworbene Klasse (hier AX3000) wenig über den AP-Betrieb aus.
- Installations-USB-Stick, Tastatur und Monitor fürs Erstsetup; Web-GUI auf Port 444 (HTTPS).
Lessons Learned
- Portbeschriftung ≠ nutzbare Bandbreite. Die PCIe-Anbindung entscheidet mit: aus „4×2,5G" wurden real 2×2,5G + 2×1G.
- Plattform auch nach Bedienbarkeit wählen. Treiberlage und die eigene Routine im Betrieb/Debugging zählen. Hier gab am Ende Linux/IPfire den Ausschlag gegenüber FreeBSD/OPNsense.
- Die scheinbar simple Komponente kann das Projekt kippen. Am WLAN-Stick ist der Access-Point-Teil gescheitert, nicht an CPU, NIC oder Firewall.
- Wissen, wann man zurückrudert. Für den Alltag ist die FRITZ!Box eingesprungen, und das ist okay. Das Projekt war technisch wie zum Basteln trotzdem ein Gewinn.
- Tiny-Formfaktor ist ein Kompromiss: ~15 W im Idle und sehr kompakt, dafür spürbar mehr unter Last und etwas Fummelei bei Riser und Kühlung.
Fazit
Als kabelgebundener 2,5-GbE-Router/Firewall hat der m720q mit IPfire funktioniert und war deutlich günstiger als eine vergleichbare Fertig-Appliance. Gescheitert ist der WLAN-Access-Point: Aus dem EDUP AX3000 kam trotz WiFi-6-Spezifikation kein brauchbarer Durchsatz (dauerhaft < 200 Mbit/s), und ausgiebige Recherche brachte keine Lösung. Für den Alltag läuft daher wieder eine FRITZ!Box (4×1 GbE).
Bereut ist davon nichts. Das Projekt hat viel über NIC-Chipsätze, PCIe-Bandbreite, den Praxisunterschied BSD/Linux und die Grenzen von Consumer-WLAN-Hardware vermittelt, und Spaß gemacht.
Eine Ironie zum Schluss: Ganz am Anfang, beim Zusammenrechnen der Teile, war mein Maßstab noch „damit bin ich immer noch günstiger als eine FRITZ!Box mit 2,5G-Ports". Am Ende hat genau diese Vergleichsmarke das WLAN übernommen. Das Preisargument stimmt weiterhin, aber die fertige Appliance kann eben Dinge, die ich mit Bordmitteln nicht in vertretbarer Zeit hinbekommen habe.
Wie es weiterging: Das Projekt ist abgeschlossen, den WLAN-Durchsatz verfolge ich nicht weiter. Der m720q läuft heute als Heimserver für andere Projekte, das Netzwerk managt die FRITZ!Box. Die Hardware war also kein Fehlkauf, sie hat nur eine andere Aufgabe bekommen als geplant.
Für die Zukunft habe ich mir stattdessen ein anderes Netzwerk-Thema vorgenommen: eine doppelte Firewall für die Maschinen und Container, deren Dienste aus dem Internet erreichbar sind. Dabei helfen genau die Erfahrungen aus diesem Projekt, Zonen-Trennung und Firewall-Regeln in der Praxis zu denken.
Woher diese Doku kommt
Der Bau lief von Anfang an als laufendes Protokoll in einer kleinen Chat-Gruppe: Ich habe jeden Schritt fotografiert, Entscheidungen erklärt und ausdrücklich um Rückfragen gebeten. Teils, weil ich gern erkläre, teils mit dem Hintergedanken, am Ende einen Blog oder eine Doku daraus zu machen. Dieses README ist genau das: mitgeschrieben während des Bauens, nicht hinterher rekonstruiert, inklusive der Umwege und der Stellen, an denen es nicht funktioniert hat.