Eine frisch installierte Container-Oberfläche lädt nicht, obwohl der Container läuft – das ist die häufigste Frustration beim Selfhosting auf dem Synology NAS. Der Schuldige ist fast immer nicht der Container selbst, sondern eine fehlende Regel in der DSM-Firewall. Diese Anleitung führt dich Schritt für Schritt durch den gesamten Ablauf: Firewall aktivieren, die Regellogik wirklich verstehen, einen Container-Port korrekt freigeben, die Quell-IP auf das lokale Netz einschränken und die Aussperr-Falle sicher umschiffen. Am Ende weißt du nach jedem einzelnen Schritt, ob alles geklappt hat.

Voraussetzungen

Synology NAS mit DSM 7.1 oder höher (empfohlen: DSM 7.2+)
Adminstratorzugang zur DSM-Oberfläche
Physischer Zugang zur NAS-Rückseite (für den Notfall-Reset-Knopf)
Netzwerkverbindung im lokalen Subnetz (LAN oder WLAN)
Bekannte Subnetz-Adresse (z. B. 192.168.1.0/24 – im Router oder unter DSM → Netzwerk → Netzwerkschnittstelle ablesen)
Port des Docker-Containers, der freigegeben werden soll (z. B. 9443/TCP für Portainer)

Schritt 1: Firewall-Status prüfen und Firewall aktivieren

Öffne in DSM die Systemsteuerung (Hauptmenü → Systemsteuerung) und navigiere zu Sicherheit → Reiter „Firewall“. Hier siehst du sofort, ob die Firewall bereits aktiv ist. Falls nicht, setze den Schalter „Firewall aktivieren“ auf Ein.

Wichtig: Aktiviere die Firewall noch nicht, wenn du noch keine Regeln angelegt hast. Eine aktive Firewall ohne explizite Allow-Regeln und mit einer Deny-All-Regel am Ende sperrt dich sofort aus. Lege zunächst alle benötigten Regeln an (Schritte 2 und 3), dann erst die Deny-All-Regel.

Falls auf deinem NAS mehrere Netzwerkschnittstellen aktiv sind (z. B. LAN1 und LAN2 bei Dual-NIC-Modellen), wähle das richtige Firewall-Profil. Ein Profil gilt immer für genau eine Schnittstelle. Stellst du das Profil auf LAN1 ein, das NAS hängt aber an LAN2, greift die Regel nicht.

Verifizieren: Der Schalter „Firewall aktivieren“ zeigt „Ein“. Im Dropdown „Netzwerkschnittstelle“ ist die Schnittstelle ausgewählt, über die du gerade auf DSM zugreifst (kontrollierbar unter Systemsteuerung → Netzwerk → Netzwerkschnittstelle).

Schritt 2: DSM-Zugang sichern – Ports 5000 und 5001 zuerst freigeben

Bevor du irgendeine Deny-Regel anlegst, musst du sicherstellen, dass du dich selbst nicht aus DSM aussperrst. Das ist die häufigste und folgenreichste Fehlerquelle überhaupt: Deny-All aktiv, kein Allow für die DSM-Ports – und der Browser meldet nur noch „Seite nicht erreichbar“.

Klicke auf „Regeln bearbeiten“ im Firewall-Bereich. Im Regeleditor klickst du auf „Erstellen“ und legst die erste Regel an:

Ports: Benutzerdefiniert → Protokoll: TCP → Portnummern: 5000,5001
Quell-IP: Spezifische IP → Subnetz, z. B. IP 192.168.1.0, Maske 255.255.255.0
Aktion: Zulassen

Speichere die Regel. Prüfe anschließend per Drag-and-Drop, dass diese Regel ganz oben in der Liste steht – neue Regeln erscheinen standardmäßig unten und müssen manuell nach oben gezogen werden.

Verifizieren: Im Regeleditor steht die Allow-Regel für Ports 5000/5001 an Position 1 der Liste. Die Spalte „Aktion“ zeigt „Zulassen“, die Spalte „Quell-IP“ zeigt dein Subnetz. Klicke noch nicht auf „Übernehmen“ – das machst du erst nach Schritt 3.

Schritt 3: Firewall-Regel für den Container-Port anlegen

Jetzt legst du die eigentliche Freigabe für deinen Docker-Container an. Das Prinzip ist identisch zu Schritt 2 – diesmal mit dem Port deines Containers. Im Beispiel verwenden wir Port 9443/TCP (Portainer). Ersetze die Portnummer durch den tatsächlichen Port deines Containers, den du in der ports-Sektion des Compose-Stacks definiert hast.

Klicke erneut auf „Erstellen“:

Ports: Benutzerdefiniert → Protokoll: TCP (oder „Beide“, wenn dein Container auch UDP benötigt) → Portnummern: 9443
Quell-IP: Spezifische IP → Subnetz, z. B. IP 192.168.1.0, Maske 255.255.255.0
Aktion: Zulassen

Schiebe diese Regel per Drag-and-Drop direkt unter die DSM-Regel aus Schritt 2, aber über einer eventuellen Deny-All-Regel. Die Reihenfolge im Regeleditor muss so aussehen:

Allow TCP 5000, 5001 vom lokalen Subnetz
Allow TCP 9443 vom lokalen Subnetz
… weitere Allow-Regeln …
Deny All (falls vorhanden – ganz unten)

Ein typischer Compose-Stack, dessen Port du so freigibst, sieht beispielsweise so aus:

services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: unless-stopped
    ports:
      - "9443:9443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /volume1/docker/portainer/data:/data

Wie du ein solches Compose-Projekt im Container Manager anlegst, beschreibt die Grund-Anleitung Container Manager auf dem Synology NAS: Docker-Compose-Projekt anlegen, starten und aktualisieren.

Verifizieren: Im Regeleditor stehen jetzt mindestens zwei Allow-Regeln. Die Reihenfolge ist korrekt (DSM-Ports oben, Container-Port darunter). Noch kein „Übernehmen“ klicken.

Schritt 4: Deny-All-Regel anlegen (optional, aber empfohlen)

Eine Deny-All-Regel am Ende der Liste sorgt dafür, dass jeder Netzwerkverkehr, für den keine explizite Allow-Regel existiert, automatisch blockiert wird. Ohne sie lässt DSM standardmäßig alles durch, was keine explizite Deny-Regel trifft. Für ein NAS ohne Portweiterleitung im Heimnetz ist das tolerierbar; sobald Ports über Router oder DDNS von außen erreichbar sind, ist Deny-All Pflicht.

Klicke auf „Erstellen“:

Ports: Alle
Quell-IP: Alle
Aktion: Verweigern

Diese Regel muss zwingend ganz unten stehen. Landet sie versehentlich über einer Allow-Regel, blockiert sie alles darunter – die Allow-Regeln werden nie ausgeführt. Prüfe die Position nochmals sorgfältig per Drag-and-Drop.

Verifizieren: Die Deny-All-Regel ist die letzte Regel in der Liste. Alle Allow-Regeln stehen darüber. Die Regelstruktur sieht aus wie in Schritt 3 beschrieben.

Schritt 5: Änderungen übernehmen

Regeln im Editor speichern und auf „OK“ klicken reicht allein nicht aus. Du musst zurück in der Firewall-Hauptansicht auf den Button „Übernehmen“ (englisch: „Apply“) klicken. Erst dann werden die Regeln aktiv und schützen – bzw. ermöglichen – den Netzwerkzugriff.

DSM zeigt nach dem Klick kurz einen Ladebalken und bestätigt die Übernahme. Ab diesem Moment gelten deine Regeln.

Verifizieren: DSM zeigt keine Fehlermeldung. Der Reiter „Firewall“ zeigt den Status „Aktiviert“ und die Regel-Anzahl entspricht dem, was du angelegt hast. Du kannst weiterhin auf DSM zugreifen (Browser-Reload zur Kontrolle).

Schritt 6: Freigabe testen

Teste die Portfreigabe von einem anderen Gerät im selben Netzwerk – nicht vom NAS selbst. Verwende außerdem niemals QuickConnect für diesen Test: QuickConnect nutzt eine Relay-Verbindung und umgeht die DSM-Firewall vollständig. Ein erfolgreicher Test über QuickConnect beweist nichts über den Firewall-Status.

Windows (PowerShell):

Test-NetConnection -ComputerName 192.168.1.x -Port 9443

Erwartetes Ergebnis bei offenem Port:

TcpTestSucceeded : True

Linux / macOS (Terminal):

nc -zv 192.168.1.x 9443

Erwartetes Ergebnis:

Connection to 192.168.1.x 9443 port [tcp/*] succeeded!

Browser-Test: Rufe https://192.168.1.x:9443 direkt über die IP-Adresse auf. Eine Zertifikatswarnung ist normal bei selbstsignierten Zertifikaten; eine leere Seite oder ein Timeout deutet dagegen auf ein Firewall-Problem hin, „Connection refused“ auf ein Container-Problem. Wenn du einen Reverse Proxy wie den Nginx Proxy Manager auf deinem NAS betreibst, findest du die benötigten zusätzlichen Port-Freigaben in der Anleitung Nginx Proxy Manager auf der Synology mit Container Manager einrichten.

Verifizieren: TcpTestSucceeded: True in PowerShell bzw. „succeeded“ in netcat. Der Browser zeigt die Container-Oberfläche (oder zumindest eine Verbindung ohne Timeout).

Schritt 7: Docker-Netzwerkbereich freigeben (optional)

Container kommunizieren intern über den Docker-Bridge-Netzwerkbereich 172.16.0.0–172.31.255.255. Wenn Container miteinander oder mit DSM-eigenen Diensten kommunizieren sollen, kann eine separate Allow-Regel für diesen Bereich sinnvoll sein:

Ports: Alle (oder gezielt die benötigten Ports)
Quell-IP: Subnetz 172.16.0.0, Maske 255.240.0.0
Aktion: Zulassen

Diese Regel stellst du ebenfalls über die Deny-All-Regel, aber nach den benutzerspezifischen Allow-Regeln.

Verifizieren: Container können auf Docker-Bridge-Adressen zugreifen. Prüfen lässt sich das via SSH mit docker exec -it <container> ping 172.17.0.1 – der NAS-Host antwortet.

Troubleshooting / Typische Fehler

Browser-Timeout, obwohl Container läuft: Firewall-Regel fehlt oder ist falsch positioniert (unter der Deny-All-Regel). Prüfe Regelreihenfolge und klicke erneut auf „Übernehmen“. Falls Container Manager neu gestartet werden muss: Systemsteuerung → Paketverwaltung → Container Manager → Stoppen/Starten, damit Docker iptables-Regeln neu schreibt.
„Connection refused“ statt Timeout: Der Port ist offen (Firewall-Regel greift), aber der Container läuft nicht oder der Port ist im Compose-Stack nicht korrekt auf den Host gemappt. Prüfe ports: in der Compose-Datei und den Container-Status im Container Manager.
Ausgesperrt nach Deny-All: DSM-Ports 5000/5001 haben keine Allow-Regel, oder diese steht unterhalb der Deny-All-Regel. → Mode-1-Reset: Reset-Knopf an der NAS-Rückseite ca. 4 Sekunden drücken bis zum Piepton. Danach NAS per find.synology.com oder Synology Assistant finden. Alle Daten und Pakete bleiben erhalten.
Regel für falsches Interface angelegt: Dual-NIC-Modelle haben LAN1 und LAN2. Die Regel gilt nur für das im Profil gewählte Interface. Lösung: Profil wechseln und Regel auch dort anlegen, oder Regel für beide Interfaces duplizieren.
Änderungen nicht wirksam nach „OK“: „OK“ im Regeleditor speichert nur, macht aber nicht aktiv. Zurück in der Firewall-Hauptansicht muss „Übernehmen“ geklickt werden.
Zuvor funktionierende Container nach DSM-Update nicht erreichbar (DSM 7.3+): Bekannter Bug ab DSM 7.3 / Build 81180 (Oktober 2025): Firewall-Regelprofile können nach Updates die Reihenfolge verlieren. Workaround: Firewall unter Systemsteuerung → Sicherheit → Firewall vorübergehend deaktivieren, NAS neu starten, Regelreihenfolge manuell prüfen und korrigieren, Firewall wieder aktivieren.
Subnetz-Maske zu groß: 255.255.0.0 statt 255.255.255.0 eingetragen – damit wird ein /16-Netz freigegeben statt /24. Immer die Maske mit einem CIDR-Rechner gegenchecken.
Protokoll falsch gewählt: Nur TCP freigegeben, Container braucht aber auch UDP. Symptom: Browser-Verbindung funktioniert, bestimmte Features nicht. Lösung: Regel auf „Beide“ umstellen oder separate UDP-Regel anlegen.

Häufige Fragen

Muss ich die DSM-Firewall im Heimnetz überhaupt aktivieren?

Wenn dein NAS ausschließlich im lokalen Netz ohne jede Portweiterleitung betrieben wird, ist die Firewall eine zusätzliche Schutzschicht, aber kein Muss. Sobald du jedoch Ports über den Router oder per DDNS von außen erreichbar machst, ist die Firewall mit Deny-All und expliziten Freigaben Pflicht – sie ist dann die letzte Verteidigungslinie vor dem offenen Internet.

Warum lädt die Web-UI meines Containers nicht, obwohl der Container läuft?

Prüfe der Reihe nach: (1) Ist der Port im Compose-Stack in der ports:-Sektion auf den Host gemappt? (2) Existiert in der DSM-Firewall eine Allow-Regel für genau diesen Port, und steht sie über der Deny-All-Regel? (3) Wurde nach der Regeländerung „Übernehmen“ geklickt? (4) Wurde Container Manager nach der Firewall-Änderung neu gestartet?

Ich habe mich ausgesperrt – was jetzt?

Mode-1-Reset: Halte den Reset-Knopf an der NAS-Rückseite ca. 4 Sekunden gedrückt, bis ein Piepton ertönt. Das NAS setzt Netzwerkeinstellungen und die Firewall zurück, alle Benutzerdaten und installierten Pakete bleiben erhalten. Danach NAS per find.synology.com oder dem kostenlosen Synology Assistant suchen, mit Admin ohne Passwort einloggen und ein neues Passwort setzen. Firewall anschließend mit korrekten Regeln neu konfigurieren.

Reicht es, die Quell-IP auf „Alle“ zu lassen?

Technisch funktioniert es, ist aber ein Sicherheitsrisiko. „Alle“ bedeutet, dass bei einer aktiven Portweiterleitung im Router auch jede beliebige IP aus dem Internet Zugriff hätte. Best Practice ist immer, die Quell-IP auf das lokale Subnetz (z. B. 192.168.1.0/24) einzuschränken.

Welche Ports muss ich für DSM selbst freigeben?

Mindestens Port 5000 (HTTP) und 5001 (HTTPS) für die DSM-Verwaltungsoberfläche. Optional Port 22 für SSH-Zugriff – SSH aktivieren und verbinden erklärt die Grund-Anleitung SSH auf dem Synology NAS aktivieren und verbinden. Diese Allow-Regeln müssen immer über der Deny-All-Regel stehen.

Wie teste ich, ob ein Port wirklich offen ist?

Nutze Test-NetConnection -ComputerName 192.168.1.x -Port 9443 in der Windows-PowerShell oder nc -zv 192.168.1.x 9443 unter Linux/macOS. TcpTestSucceeded: True bzw. „succeeded“ bestätigt einen offenen Port. Ein Timeout (nicht „Connection refused“) bedeutet, dass die Firewall blockt.

QuickConnect funktioniert – heißt das, der Port ist offen?

Nein. QuickConnect nutzt eine Relay-Verbindung über Synologys Server und umgeht die DSM-Firewall vollständig. Ein erfolgreicher QuickConnect-Zugriff beweist nur, dass der Container läuft, sagt aber nichts über den Firewall-Status aus. Teste immer mit der direkten IP-Adresse.

Fazit

Die DSM-Firewall ist kein Hexenwerk – aber sie verlangt Disziplin bei der Reihenfolge: DSM-Ports zuerst sichern, dann Container-Ports freigeben, Deny-All ganz unten, und am Ende wirklich auf „Übernehmen“ klicken. Wer diesen Ablauf einmal verinnerlicht hat, wird die Aussperr-Falle nie wieder erleben. Mit dem Test-NetConnection-Befehl aus der PowerShell hast du außerdem ein schnelles Werkzeug, das dir nach jeder Regeländerung in Sekunden zeigt, ob der Port wirklich erreichbar ist – ohne auf Browser-Timeouts warten zu müssen. Für jeden weiteren Container, den du auf deinem NAS betreibst, ist die Firewall-Freigabe dann nur noch eine Routine von zwei Minuten.

Weiterführende Anleitungen und Quellen

Quellen: Synology Knowledge Center – DSM 7 Firewall Help (kb.synology.com); Synology Knowledge Center – How to Reset My Synology NAS (kb.synology.com); Marius Hosting – How to Correctly Set Up Firewall on DSM 7 (mariushosting.com); heimnetz.de – Synology Firewall einrichten (heimnetz.de).