Scanner + Paperless sicher im isolierten IoT-VLAN

Scanner + Paperless sicher im isolierten IoT-VLAN

Ein Netzwerkscanner ist ein Stück Hardware mit eigener Firmware, Cloud-Funktionen und seltenen Updates - also ein klassischer Kandidat fürs IoT-VLAN. Die Frage war: Wie scannt er trotzdem direkt in meinen Paperless-Ordner, ohne dass ich die Netzwerk-Trennung aufweiche? Es reicht eine einzige Firewall-Regel. Diesen Weg beschreibe ich hier - samt der Stelle, an der das Setup an eine Protokoll-Grenze stößt.

DarkWolfCave.de

ℹ️ Voraussetzungen: Ein Router mit VLAN-Support und zonenbasierter Firewall (bei mir UniFi), ein laufendes Paperless-NGX und ein Scanner, der per SMB in einen Netzwerkordner scannen kann. Welcher Scanner sich dafür eignet, habe ich im Dokumentenscanner-Vergleich für Paperless durchgespielt.

Nachdem die Hardware-Frage geklärt war, stand bei mir ein Brother ADS-4700W auf dem Schreibtisch. Der scannt per LAN oder WLAN autonom in einen SMB-Ordner, ganz ohne angeschlossenen PC. Praktisch - aber genau das ist auch der Punkt, an dem die meisten Anleitungen aufhören: Sie stellen den Scanner einfach ins Hauptnetz neben den Server.

Das wollte ich nicht. Ein Scanner ist für mich ein IoT-Gerät: geschlossene Firmware, gelegentliche Telefonate nach Hause, Updates kommen unregelmäßig. So ein Gerät gehört bei mir ins isolierte IoT-VLAN, das per Default keinen Weg in die anderen Netze hat. Die Aufgabe war also, ihm genau einen Weg zu öffnen - den zum consume-Ordner - und sonst nichts.

Warum der Scanner ins isolierte IoT-VLAN gehört

Die Netzwerk-Segmentierung folgt bei mir dem gleichen Gedanken wie bei Home Assistant hinter VLANs: Geräte, denen ich nicht vollständig vertraue, kommen in ein eigenes Segment, das vom Rest abgeschottet ist. Smart-Home-Steckdosen, Kameras, Streaming-Hardware - und eben der Scanner.

Der Default im IoT-VLAN ist: Internet ja, Zugriff auf andere VLANs nein. Wenn die Firmware des Scanners eine Lücke hätte oder das Gerät unerwünscht Verbindungen aufbauen wollte, käme es schlicht nicht an meine internen Dienste heran. Das ist die Grundlage von Zero-Trust im Heimnetz: nicht das ganze Netz dichtmachen, sondern jedem Gerät nur die Verbindungen erlauben, die es nachweislich braucht.

Für den Scanner heißt das: Er braucht genau eine ausgehende Verbindung in mein internes Netz - zum Paperless-Server, auf den SMB-Port. Mehr nicht.

Mein Setup im Überblick

Die Eckdaten meines Aufbaus, damit die Konfiguration nachvollziehbar ist:

| Komponente | Netz | Adresse | |-----------|------|---------| | Scanner (Brother ADS-4700W) | IoT-VLAN (isoliert) | 192.168.20.246 | | Paperless-Server | internes LAN | 192.168.1.36 | | Mac (gelegentliche Verwaltung) | privates VLAN | dynamisch |

Der Paperless-Server ist bei mir ein Raspberry Pi 5, auf dem Paperless-NGX in Docker läuft. Der consume-Ordner liegt im Paperless-Datenverzeichnis und wird per Samba als Share consume nach außen gegeben. Der Scanner bekommt eine feste IP, damit ich ihn gezielt in einer Firewall-Regel ansprechen kann - dynamische Adressen taugen für Quell-Regeln nicht.

Der entscheidende Punkt: Scanner und Paperless-Server stehen in unterschiedlichen VLANs, zwischen denen die Firewall standardmäßig alles blockt.

Die eine Firewall-Regel, die autonomes Scannen ermöglicht

UniFi arbeitet inzwischen mit zonenbasierten Firewall-Regeln, und zwischen den Zonen ist der Verkehr per Default geblockt. Für den autonomen Scan-Workflow brauche ich exakt eine Allow-Regel:

# Scanner darf in den consume-Ordner schreiben
Action:      Allow
Source:      192.168.20.246   (Scanner, IoT-VLAN)
Destination: 192.168.1.36     (Paperless-Server, internes LAN)
Port:        TCP 445          (SMB, beim Ziel)
Auto Allow Return Traffic: AN

Wichtig sind zwei Details. Erstens steht der Port immer bei der Destination, der Source-Port bleibt Any - der Scanner verbindet sich von einem zufälligen hohen Port aus zum festen Port 445 des Servers. Zweitens die Option Auto Allow Return Traffic: Sie macht die Regel stateful, sodass die Antwortpakete des Servers automatisch zurückdürfen. Ohne sie müsstest du eine zweite Regel für den Rückweg bauen.

Das ist die ganze Öffnung. Der Scanner kann jetzt SMB zum Paperless-Server sprechen - und sonst nichts. Er kommt weiterhin nicht an mein NAS, nicht an andere Server, nicht in andere VLANs.

Diese Regel erlaubt ausschließlich die Richtung Scanner → Server auf einem einzigen Port. Wenn du den Scanner zusätzlich vom Rechner aus verwalten willst (Web-Oberfläche, Scan vom Mac), brauchst du dafür separate Regeln in die Gegenrichtung. Halte die so eng wie möglich - jede zusätzliche Regel ist ein Loch, das du bewusst bohrst.

Paperless: SMB-Share und das Polling-Detail

Auf dem Server liegt der consume-Ordner im Paperless-Datenverzeichnis. Ich gebe ihn per Samba frei und lege einen eigenen Benutzer dafür an:

# Samba-Benutzer für den Scan-Zugriff setzen
sudo smbpasswd -a SCAN_USER

Die Authentifizierung läuft über NTLMv2, nur mit Benutzername, ohne Domäne. Das ist später am Scanner wichtig, weil Brother-Geräte sonst eine Domäne erwarten, die es im Heimnetz nicht gibt.

Der Stolperstein, der mich am Anfang Zeit gekostet hat, steckt in Paperless selbst. Paperless erkennt neue Dateien im consume-Ordner normalerweise über inotify - das ist ein Kernel-Mechanismus, der lokale Dateisystem-Änderungen meldet. Über ein Netzwerk-Dateisystem wie SMB feuert inotify aber nicht zuverlässig. Die Scans landen im Ordner, und nichts passiert.

⚠️ Wichtig: Bei einem SMB-consume-Ordner musst du das Polling aktivieren. Paperless schaut dann in festen Intervallen aktiv nach neuen Dateien, statt auf inotify-Events zu warten.

Die relevanten Umgebungsvariablen in der Paperless-Konfiguration:

# Aktiv pollen statt auf inotify zu warten (Sekunden)
PAPERLESS_CONSUMER_POLLING=10
# Unterordner mit einlesen
PAPERLESS_CONSUMER_RECURSIVE=true
# Unterordner-Namen als Tags übernehmen
PAPERLESS_CONSUMER_SUBDIRS_AS_TAGS=true

| Variable | Wirkung | |----------|---------| | PAPERLESS_CONSUMER_POLLING | Intervall in Sekunden, in dem der consume-Ordner aktiv geprüft wird. Pflicht bei SMB. | | PAPERLESS_CONSUMER_RECURSIVE | Auch Unterordner des consume-Verzeichnisses werden eingelesen. | | PAPERLESS_CONSUMER_SUBDIRS_AS_TAGS | Legst du eine Datei in consume/rechnungen/, bekommt das Dokument automatisch den Tag rechnungen. |

Wenn du Paperless noch gar nicht stehen hast, beschreibt der Artikel Paperless mit Docker installieren den kompletten Aufbau - das Polling ist dort die einzige Anpassung, die du für den Netzwerk-Scan zusätzlich brauchst.

Scan-Profil am Brother ADS-4700W einrichten

Den Rest erledige ich im Web Based Management des Scanners, das ich über die Scanner-IP im Browser erreiche. Unter Scannen → FTP/SFTP/Netzwerk/SharePoint wähle ich als Typ Netzwerk - das ist bei Brother die Bezeichnung für SMB. Im zugehörigen Profil trage ich ein:

Netzwerkordnerpfad:  \\192.168.1.36\consume
Authentifizierung:   NTLMv2
Benutzername:        SCAN_USER
Passwort:            (das Samba-Passwort)

💡 Tipp: Verwende im Netzwerkpfad die IP-Adresse, nicht den Hostnamen. Damit umgehst du die NetBIOS-Namensauflösung, die über VLAN-Grenzen ohnehin nicht funktioniert. Falls der Scanner den Pfad mit führenden Backslashes ablehnt, probiere ihn ohne die \\ davor.

Für den Workflow mit Paperless haben sich diese Profil-Einstellungen bewährt:

• Dateityp: PDF mehrseitig - ein Stapel wird zu einem Dokument, nicht zu 30 Einzelseiten.
• Dokumententrennung: Aus - sonst zerlegt der Scanner den Stapel an Leerseiten in mehrere Dateien.
• 2-seitig: Ein - Duplex spart die Hälfte der Durchläufe.
• Erkennung Mehrfacheinzug: Ein - der Ultraschall-Sensor meldet, wenn zwei Blätter gleichzeitig durchrutschen.
• Leerseite überspringen: Ein - Rückseiten ohne Inhalt landen nicht im Archiv.

Ein Druck auf die Taste am Scanner, der Stapel läuft durch, die PDF landet im consume-Ordner, und nach spätestens zehn Sekunden zieht Paperless sie ein, macht OCR und vergibt die Tags. Kein PC dazwischen, und der Scanner war zu keinem Zeitpunkt aus seinem VLAN heraus erreichbar.

VIP Support

Du wirst hier einen groben Überblick finden.
Allerdings biete ich dir auch noch etwas mehr Support an:

• Du benötigst persönlichen Support
• Du möchtest von Beginn an Unterstützung bei deinem Projekt
• Du möchtest ein hier vorgestelltes Plugin durch mich installieren und einrichten lassen
• Du würdest gerne ein von mir erstelltes Script etwas mehr an deine Bedürfnisse anpassen

Für diese Punkte und noch einiges mehr habe ich einen limitierten VIP-Tarif eingerichtet.

VIP-Patreon Tarif Discord kontaktieren

Falls der Tarif gerade nicht verfügbar ist, kontaktiere mich auf Discord!

mDNS ist nicht die Firewall - der Unterschied, der alles erklärt

Bis hierhin läuft alles über feste IPs und eine Firewall-Regel. Kein mDNS, kein Bonjour, keine Auto-Discovery. Das ist die schlanke Variante, und sie reicht für den autonomen Scan vollständig aus.

Komfort kommt erst ins Spiel, wenn ich vom Mac aus auf den Scanner zugreifen will - etwa um per macOS-Bordmitteln über eSCL/AirScan zu scannen oder die Weboberfläche aufzurufen. Hier taucht der Scanner zunächst gar nicht auf, weil die Geräteerkennung über mDNS läuft und mDNS standardmäßig an der VLAN-Grenze endet.

Hier lohnt eine Unterscheidung, die im Heimnetz vieles erklärt:

• mDNS ist Discovery - das Finden eines Geräts und seiner Dienste. Es läuft über Multicast (UDP 5353) und bleibt normalerweise im eigenen VLAN.
• Die Firewall regelt den Transport - das tatsächliche Erreichen eines Geräts auf einem Port.

Daraus folgt eine simple Regel: Dienste, bei denen du die Ziel-IP von Hand eingibst, brauchen kein mDNS - nur eine Firewall-Regel. Das gilt für den SMB-Scan, fürs NAS-Mounten per IP, für SSH, für Weboberflächen. mDNS brauchst du nur dort, wo es keine IP-Eingabe gibt, etwa beim Scannen direkt vom iPhone oder bei AirPlay.

Damit der Mac den Scanner findet, kann man im UniFi-Gateway einen mDNS-Proxy aktivieren, der Dienste cross-VLAN sichtbar macht.

🔒 Sicherheit: Der mDNS-Proxy öffnet kein Zugriffs-Loch - er macht nur Geräte sichtbar, den Zugriff blockt weiter die Firewall. Aber ein Service-Scope All weicht die Isolation auf, weil dann alle Dienste aller IoT-Geräte in den anderen VLANs auftauchen. Ich habe den Scope auf Specific gestellt und nur den einen Dienst zugelassen, den ich brauche. Server-artige Dienste (SMB, SSH, Web) bleiben bewusst draußen, weil ich sie ohnehin per IP und Firewall erreiche.

Wo das Setup an seine Grenze stößt: AirPlay 2 über VLANs

Jetzt zum Teil, den die meisten Setup-Anleitungen verschweigen, weil er nicht funktioniert. Sobald im IoT-VLAN auch AirPlay-Ziele stehen - bei mir ein Apple TV und ein Yamaha-Gerät mit MusicCast - stellt sich die Frage, ob man vom iPhone aus dem privaten VLAN dorthin streamen kann. Die Antwort ist: nein. Und das ist kein Konfigurationsfehler, sondern eine Grenze des Protokolls.

Ich habe das über einen längeren Abend durchgemessen. Im selben VLAN (iPhone testweise ins IoT-WLAN) läuft AirPlay einwandfrei. Über die VLAN-Grenze scheitert es zuverlässig.

Der Grund liegt in der Zeitsynchronisation. AirPlay 2 synchronisiert die Wiedergabe über PTP (Precision Time Protocol, UDP 319/320), und PTP nutzt dafür eine Multicast-Adresse aus dem Local Network Control Block (224.0.0.0/24 - für PTP ist dort die Adresse 224.0.0.107 registriert). Adressen aus diesem Block dürfen laut RFC 5771 das lokale Subnetz niemals verlassen - jeder Router, auch UniFi, verwirft diese Pakete. Discovery und der eigentliche Audio-Stream gehen cross-VLAN durch, nur die PTP-Synchronisation nicht. Ohne sie kommt die AirPlay-2-Session nicht zustande.

UniFi kann das nicht lösen, und das ist keine Bequemlichkeit der Hersteller:

• Der mDNS-Proxy macht nur Discovery (UDP 5353), keine Multicast-Weiterleitung.
• IGMP-Snooping und Multicast-Optimierung wirken nur innerhalb eines VLANs.
• Es gibt kein Multicast-Routing (PIM) in UniFi, mit dem man link-local Multicast weiterreichen könnte - was bei diesem Adressblock per Definition auch gar nicht erlaubt wäre.
• AirPlay 1 (das ohne PTP auskam) lässt sich auf aktuellem iOS nicht erzwingen.

Das deckt sich mit dem Konsens der Community und der Praxis bei Geräten wie Sonos: AirPlay-Quelle und -Ziel müssen im selben VLAN liegen.

Meine Lösung ist deshalb unspektakulär: Wenn ich streamen will, hängt sich das iPhone kurz ins IoT-WLAN ein - dann läuft AirPlay intra-VLAN. Die Segmentierung bleibt strikt, ich baue nichts um. Die Alternativen (AirPlay-Ziele ins private VLAN holen oder ein eigenes Media-VLAN aufsetzen) habe ich verworfen: Die eine kostet Isolation, die andere Aufwand für ein Problem, das ein WLAN-Wechsel löst.

Eine Beobachtung als Randnotiz, weil sie für die Lösung egal ist: Mein Mac bekommt AirPlay cross-VLAN trotzdem hin, das iPhone nicht. Warum macOS sich beim PTP-Handling anders verhält, habe ich nicht abschließend geklärt - für die Praxis ist es ohne Belang.

Debugging cross-VLAN: was mir geholfen hat

Die Methoden aus dem AirPlay-Abend lassen sich auf jedes Problem übertragen, bei dem etwas über VLAN-Grenzen nicht will. Sie trennen sauber zwischen Netzwerk- und App-Ebene:

• Reachability ohne App testen: Hat das Ziel einen Webserver, rufe vom Quellgerät aus http://ZIEL-IP im Browser auf. Lädt die Seite, ist der Unicast-Transport offen und die Firewall passt. Timeout heißt: Der Pfad ist zu - dann liegt es nicht an der App.
• Discovery von Transport trennen: Erscheint das Ziel überhaupt in der Geräteliste? Ja, aber die Verbindung scheitert → Transport- oder Protokollproblem. Nein → ein Discovery-/mDNS-Thema.
• iPhone und Mac gegen dasselbe Ziel testen: Klappt es auf einem Gerät und auf dem anderen nicht, ist das Problem gerätespezifisch, nicht netzwerkweit.
• iOS-Stolpersteine prüfen: “IP-Adresse beschränken” (pro WLAN, im Heimnetz aus), iCloud Private Relay und ein aktives VPN leiten lokalen Verkehr um oder blockieren ihn. Bei zickigem lokalem Traffic zuerst dort schauen.

Mit diesen vier Handgriffen landet man schnell bei der richtigen Ebene, statt blind an Firewall-Regeln zu drehen, wenn das Problem in Wahrheit beim mDNS oder einer iOS-Einstellung sitzt.

Meine Einschätzung

Der Aufwand, einen Scanner sauber zu isolieren und trotzdem autonom scannen zu lassen, ist kleiner als gedacht: eine feste IP, eine Firewall-Regel auf Port 445, ein Samba-Share und das Polling in Paperless. Damit bleibt das IoT-VLAN dicht, und der Scan-Workflow ist genau so bequem wie im Flachnetz - Stapel rein, Taste drücken, Paperless zieht die PDF ein.

Die Grenze des Setups ist AirPlay 2. Sie hat mich einen Abend gekostet, bis klar war, dass kein UniFi-Schalter sie öffnet, weil das Limit im Protokoll liegt, nicht in der Konfiguration. Der WLAN-Wechsel beim Streamen ist ein Kompromiss, aber ein kleiner - und er erhält die Trennung, auf die es mir ankommt.

Was bleibt, ist die Unterscheidung zwischen Discovery und Transport. Mit ihr baut man im Heimnetz schlanke Regeln, statt mDNS überall aufzureißen: feste IP plus Firewall für alles, wo man die Adresse eingeben kann, und mDNS nur für die wenigen Dienste, die ohne Auto-Discovery nicht funktionieren.

Weiterführende Artikel

• Dokumentenscanner für Paperless-NGX im Vergleich - Welcher Scanner zum Setup passt, mit Specs und SMB-Workflow
• Paperless-NGX mit Docker installieren - Komplette Installationsanleitung als Basis
• Paperless-NGX sichern - Backup und Restore - Damit das digitalisierte Archiv nicht an einem Ort hängt
• Home Assistant mit Traefik, VLANs und Netzwerk-Segmentierung - Der gleiche Isolations-Gedanke fürs Smart Home
• Firewall & Zero-Trust: Netzwerk schichtweise absichern - Warum jedes Gerät nur die Verbindungen bekommt, die es braucht