Tuxipedia - Benutzerbeiträge [de]

Robert Franz (1815-1892), deutscher Komponist

2026-05-31T13:49:57Z

Admin: /* Die Lieder */

{{DISPLAYTITLE:Robert Franz}}
[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]
Robert Franz (eigentlich Robert Franz Julius Knauth; * 28. Juni 1815 in Halle an der Saale; † 24. Oktober 1892 ebenda) war ein deutscher Komponist, Organist und Dirigent. Zu Lebzeiten von Zeitgenossen wie Robert Schumann, Franz Liszt und Felix Mendelssohn geschätzt, gehört er heute zu den weitgehend vergessenen Komponisten der deutschen Romantik.

[[Datei:Robert Franz.jpg|thumb|right|250px|Robert Franz (1815–1892)]]

== Leben ==

=== Herkunft und Ausbildung ===

Robert Franz stammte aus einer alteingesessenen Hallorer-Familie. (Siehe auch: [[Halloren]]).
Er wuchs in Halle auf, wo er ab 1828 die Latina der Franckeschen Stiftungen besuchte. Früh fiel er durch musikalische Begabung auf; der dortige Kantor Carl Gottlob Abela ließ ihn die Proben des Schulchors am Klavier begleiten. Von 1835 bis 1837 studierte er Komposition bei Friedrich Schneider in Dessau und kehrte danach nach Halle zurück – in eine Stadt, die er zeit seines Lebens kaum verlassen sollte.

=== Berufliche Laufbahn in Halle ===

Nach schwierigen wirtschaftlichen Anfangsjahren übernahm Franz 1841 das Organistenamt an der Ulrichskirche. Im folgenden Jahr wurde er Dirigent der Singakademie Halle, die später seinen Namen annahm. 1848 heiratete er Marie Hinrichs, Tochter eines Professors und selbst Komponistin; das Paar hatte drei Kinder. 1859 wurde Franz schließlich zum Universitätsmusikdirektor ernannt – der Höhepunkt seiner öffentlichen Laufbahn.

=== Krankheit und Rückzug ===

Seit 1843 litt Franz an einem Nerven- und Ohrenleiden, das sich über Jahrzehnte progressiv verschlimmerte und schließlich zur vollständigen Taubheit führte. 1867 wurde er beurlaubt,
1868 musste er alle Ämter endgültig aufgeben. Die daraus folgende finanzielle Not war erheblich: Ein 1867 zuerkannter Ehrensold wurde ihm 1877 auf Betreiben von Widersachern wieder entzogen. Seinen Lebensunterhalt sicherte schließlich ein 1873 von Freunden und Kollegen – allen voran Franz Liszt – gestifteter Ehrenfonds in Höhe von 30.000 Talern.

Die letzten rund 25 Jahre seines Lebens verbrachte Franz in nahezu vollständiger Taubheit und sozialem Rückzug. Er starb am 24. Oktober 1892 in Halle.

1885 wurde ihm zu seinem 70. Geburtstag – anlässlich der Feier des 200. Geburtstags Georg Friedrich Händels – das Ehrenbürgerrecht der Stadt Halle verliehen.

=== Familie ===

1848 heiratete Robert Franz in Halle Marie Hinrichs (1828–1891),
Tochter des Hallenser Philosophieprofessors Hermann Friedrich
Wilhelm Hinrichs. Marie Franz war selbst Komponistin und hatte bereits 1846 – also
zwei Jahre vor der Heirat – bei Breitkopf & Härtel in Leipzig einen
Band mit neun Gesängen für Singstimme und Klavier veröffentlicht.

Dem Paar wurden drei Kinder geboren. Bekannt sind: ein Sohn, der
1900 als praktischer Arzt in Heidelberg starb, sowie eine Tochter,
die den Superintendenten Bethge in Giebichenstein heiratete.

Marie Franz starb 1891. Robert Franz,
taub und weitgehend isoliert, überlebte sie um ein Jahr.
Beide sind auf dem Stadtgottesacker in Halle begraben.

[[Datei:Robert-franz-im-alter.png |thumb|right|250px|Robert Franz, späte Aufnahme]]

== Das Werk ==

=== Die Lieder ===

Robert Franz schrieb über 350 Kunstlieder für Singstimme und Klavier – und fast ausschließlich das. Keine Symphonien, keine Opern, kein Streichquartett. Diese bewusste Konzentration auf eine einzige Gattung war seine Stärke und zugleich der Grund für sein späteres Vergessen.

Etwa ein Viertel seiner Lieder vertont Texte von Heinrich Heine. Daneben war Karl Wilhelm Osterwald ein bevorzugter Dichter. Franz' Vertonungsweise gilt als außerordentlich textgetreu und harmonisch differenziert – ohne Effekthascherei, in großer Zurückhaltung und mit feinem Klangsinn. Robert Schumann, dem Franz 1843 sein erstes gedrucktes Heft (op. 1, ''Zwölf Gesänge'') zuschickte, antwortete, die Lieder hätten ihm gefallen „wie seit langer Zeit keine mehr". Auch Mendelssohn, Liszt und Wagner äußerten sich anerkennend.

Zu den heute noch gelegentlich aufgeführten Liedern gehören:
* ''Aus meinen großen Schmerzen'', op. 5 Nr. 1 (Text: Heinrich Heine)
* ''Auf dem Meere'', op. 5 Nr. 3 (Text: Heinrich Heine)
* ''Sterne mit den goldnen Füßchen'', op. 30 Nr. 1 (Text: Heinrich Heine)
* ''Schilflieder'', op. 2 (Text: Nikolaus Lenau)

=== Bearbeitungen von Bach und Händel ===

Neben seinen Liedern hat Franz einen – heute kaum noch bekannten,
aber musikhistorisch aufschlussreichen – Teil seiner Energie in die
Bearbeitung älterer Musik investiert. Als Leiter der Singakademie
musste er Werke von Bach und Händel aufführbar machen – und das
bedeutete im 19. Jahrhundert: eingreifen.

Konkret tat er dreierlei:

* '''Generalbassaussetzung:''' Die in Barockpartituren nur als bezifferter oder unbezifferter Bass notierten Begleitstimmen schrieb er vollständig aus – für Klavier oder Orchester.

* '''Uminstrumentierung:''' Barockbesetzungen ersetzte er durch das romantische Orchester. Cembalo, Gambe, Oboe d'amore – all das wurde durch zeitgenössische Instrumente ersetzt.

* '''Ergänzung fehlender Stimmen:''' Wo Partituren lückenhaft überliefert waren, schrieb er fehlende Stimmen hinzu.

Das Ergebnis war kein historisches Bach oder Händel, sondern Bach
und Händel im romantischen Gewand – aufführungspraktisch für das
19. Jahrhundert gedacht, ästhetisch aber von Anfang an umstritten.

Genau hier lag der Kern des späteren Streits mit Friedrich
Chrysander und Philipp Spitta (siehe [[#Der Bearbeitungsstreit|
Der Bearbeitungsstreit]]): nicht ob man den Generalbass aussetzen
darf, sondern ''wie'' – und ob dabei die Klangsprache des
19. Jahrhunderts legitim ist.

== Der Bearbeitungsstreit ==

Franz' Ergänzungen des barocken Generalbasssatzes – also seine Ausführung der in Barockpartituren nur skizzenhaft notierten Begleitung – stießen auf scharfen Widerspruch der aufkommenden philologisch-historischen Schule. Besonders Friedrich Chrysander, Herausgeber der Händel-Gesamtausgabe, und Philipp Spitta, der maßgebliche Bach-Forscher der Zeit, kritisierten Franz' Herangehensweise als zu romantisierend und zu wenig historisch korrekt.

Franz seinerseits ließ sich das nicht gefallen. In einem [[Brief vom 1. Februar 1871 | Brief]] an seinen Freund Julius Schäffer schrieb er über Chrysander:

: ''„Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne gepachtet zu haben."''

Der Streit wurde auch öffentlich geführt. Schäffer verfasste zwischen 1875 und 1880 eine Reihe von Streitschriften zur Verteidigung der Franz'schen Bearbeitungen, darunter ''Entgegnung auf Ph. Spitta's Artikel: Über das Accompagnement in den Kompositionen Seb. Bachs'' und ''Friedr. Chrysander in seinen Klavierauszügen zur deutschen Händel-Ausgabe''. Franz selbst meldete sich mit einem ''Offenen Brief an Eduard Hanslick'' und den ''Mitteilungen über J. S. Bachs Magnificat'' zu Wort.

Auf Seiten der Franz'schen Bearbeitungen standen namhafte Praktiker wie Liszt, Felix Mottl, Hans Richter und Arthur Nikisch. Die philologische Schule – Chrysander, Spitta – pochte auf Texttreue.

Dieser Streit ist im Kern derselbe, der bis heute nicht wirklich entschieden ist: Wie viel interpretatorische Freiheit darf – oder muss – eine lebendige Aufführung alter Musik haben? Franz stand auf der Seite der musikalischen Praxis; die Gegenseite bereitete den Boden für das vor, was später als Historisch Informierte Aufführungspraxis bekannt werden sollte.

== Warum ist Robert Franz vergessen? ==

Das ist eine berechtigte Frage – und die Antwort ist vielschichtig:

* '''Das Gattungsproblem:''' Franz schrieb fast ausschließlich Lieder. Im 20. Jahrhundert rückte das Kunstlied zunehmend an den Rand des Konzertlebens. Komponisten, die auch Symphonien, Kammermusik oder größere Vokalwerke hinterlassen haben – Brahms, Schumann, Schubert –, blieben im Repertoire präsent. Franz nicht.

* '''Kein zyklisches Hauptwerk:''' Anders als Schubert mit der ''Winterreise'' oder der ''Schönen Müllerin'' hinterließ Franz keinen Liederzyklus, der als geschlossenes Abendprogramm funktioniert und vermarktbar ist.

* '''Kein überregionales Netzwerk:''' Franz lebte und arbeitete sein Leben lang in Halle. Er hatte keine Schüler, die seine Tradition weitergetragen hätten, und keine Präsenz in den großen Musikzentren Wien, Leipzig oder Berlin.

* '''Die Taubheit:''' 25 Jahre Isolation am Ende seines Lebens bedeuteten: kein Spätwerk, keine Weiterentwicklung, keine späten Meisterwerke wie bei Beethoven oder Schubert.

Schumann hatte Franz übrigens bereits früh ermahnt, sich nicht auf das Lied zu beschränken. Franz blieb trotzdem bei seiner Wahl – konsequent und ohne Kompromisse.

== Zeitgenössische Wertschätzung ==

Dass Franz zu Lebzeiten keineswegs unbekannt war, zeigt eine Episode aus dem Jahr 1873: Als seine finanzielle Lage nach dem Verlust seiner Ämter und Bezüge prekär wurde, organisierten Franz Liszt und andere namhafte Musikerpersönlichkeiten einen Ehrenfonds, der Franz den Lebensunterhalt sicherte. Liszt hatte zudem bereits 1872 eine Monographie über Franz verfasst.

== Weblinks und Quellen ==

* [https://www.deutsche-biographie.de/sfz16975.html Deutsche Biographie – Robert Franz] (Allgemeine Deutsche Biographie, Band 48, 1904)
* [https://de.wikipedia.org/wiki/Robert_Franz Wikipedia – Robert Franz]
* [https://www.musikland-sachsenanhalt.de/beitraege/franz-robert-1815-1892/ Musikland Sachsen-Anhalt – Robert Franz]
* [https://halle.de/kultur-tourismus/stadtgeschichte/bekannte-persoenlichkeiten/beruehmte-hallenser/details/franz-robert Berühmte Hallenser – Stadt Halle]
* [https://st.museum-digital.de/object/1102 Brief von Robert Franz an Julius Schäffer, 1. Februar 1871] – Stiftung Händel-Haus Halle (museum-digital Sachsen-Anhalt)
* [https://www.klassik-heute.com/4daction/www_komponist?id=43036&bio= Klassik Heute – Biographie Robert Franz]

----
''Seite erstellt im Kontext eines Konzertprogramms mit Liedern von Robert Franz, Mai 2026.''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:54:01Z

Admin: /* Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt hier verschiedene Anbieter, oft auch kostenlose.

'''Beispiel:''' Der eigenen, von außen sichtbaren IP 78.123.234.45 wird vom DynDDS-Dienst die Domain <myhomeserver.dyndns.de> zugewiesen.
Einmal eingerichtet, wird der eigene Rechner antworten, wenn die Domain http://myhomeserver.dyndns.de in die Browser-Adressleiste einkopiert wird. Bei mir war damals die Freude darüber groß.

=== Motivation für einen Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar.
Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Kurz: Eine öffentliche Erreichbarkeit des eigenen Servers über die ungesicherte Adresse...

* http://myhomeserver.dyndns.de

...wäre hochgradig fahrlässig.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer schon einmal aufgrund "zu..." vieler unbeabsichtigter Fehlversuche während der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus teilen!)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen und, abgesehen von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Sollte das keine Option sein: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen).
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine(!) externen Freigaben!'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts.
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren.

Abschließend eine absolute Regel, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:51:30Z

Admin: /* Sicherheitshinweise */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

Beispiel: Der eigenen, von außen sichtbaren IP 78.123.234.45 wird vom DynDDS-Dienst die Domain <myhomeserver.dyndns.de> zugewiesen.
Einmal eingerichtet, wird der eigene Rechner antworten, wenn die Domain http://myhomeserver.dyndns.de in die Browser-Adressleiste einkopiert wird.

=== Motivation für einen Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar.
Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Kurz: Eine öffentliche Erreichbarkeit des eigenen Servers über die ungesicherte Adresse...

* http://myhomeserver.dyndns.de

...wäre hochgradig fahrlässig.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer schon einmal aufgrund "zu..." vieler unbeabsichtigter Fehlversuche während der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus teilen!)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen und, abgesehen von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Sollte das keine Option sein: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen).
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine(!) externen Freigaben!'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts.
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren.

Abschließend eine absolute Regel, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:50:55Z

Admin: /* Sicherheitshinweise */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

Beispiel: Der eigenen, von außen sichtbaren IP 78.123.234.45 wird vom DynDDS-Dienst die Domain <myhomeserver.dyndns.de> zugewiesen.
Einmal eingerichtet, wird der eigene Rechner antworten, wenn die Domain http://myhomeserver.dyndns.de in die Browser-Adressleiste einkopiert wird.

=== Motivation für einen Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar.
Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Kurz: Eine öffentliche Erreichbarkeit des eigenen Servers über die ungesicherte Adresse...

* http://myhomeserver.dyndns.de

...wäre hochgradig fahrlässig.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer schon einmal aufgrund "zu..." vieler unbeabsichtigter Fehlversuche während der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus teilen!)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen und, abgesehen von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Sollte das keine Option sein: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine(!) externen Freigaben!'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regel, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:50:10Z

Admin: /* Sicherheitshinweise */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

Beispiel: Der eigenen, von außen sichtbaren IP 78.123.234.45 wird vom DynDDS-Dienst die Domain <myhomeserver.dyndns.de> zugewiesen.
Einmal eingerichtet, wird der eigene Rechner antworten, wenn die Domain http://myhomeserver.dyndns.de in die Browser-Adressleiste einkopiert wird.

=== Motivation für einen Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar.
Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Kurz: Eine öffentliche Erreichbarkeit des eigenen Servers über die ungesicherte Adresse...

* http://myhomeserver.dyndns.de

...wäre hochgradig fahrlässig.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer schon einmal aufgrund "zu..." vieler unbeabsichtigter Fehlversuche während der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus teilen!)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen und, abgesehen von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Sollte das keine Option sein: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regel, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:47:33Z

Admin: /* Annahmen / Szenario */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

Beispiel: Der eigenen, von außen sichtbaren IP 78.123.234.45 wird vom DynDDS-Dienst die Domain <myhomeserver.dyndns.de> zugewiesen.
Einmal eingerichtet, wird der eigene Rechner antworten, wenn die Domain http://myhomeserver.dyndns.de in die Browser-Adressleiste einkopiert wird.

=== Motivation für einen Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar.
Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Kurz: Eine öffentliche Erreichbarkeit des eigenen Servers über die ungesicherte Adresse...

* http://myhomeserver.dyndns.de

...wäre hochgradig fahrlässig.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer schon einmal aufgrund "zu..." vieler unbeabsichtigter Fehlversuche während der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus teilen!)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen und, abgesehen von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regel, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:44:52Z

Admin: /* Motivation für einen Server mit OPNsense, Managed Switch und Docker */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

Beispiel: Der eigenen, von außen sichtbaren IP 78.123.234.45 wird vom DynDDS-Dienst die Domain <myhomeserver.dyndns.de> zugewiesen.
Einmal eingerichtet, wird der eigene Rechner antworten, wenn die Domain http://myhomeserver.dyndns.de in die Browser-Adressleiste einkopiert wird.

=== Motivation für einen Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar.
Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Kurz: Eine öffentliche Erreichbarkeit des eigenen Servers über die ungesicherte Adresse...

* http://myhomeserver.dyndns.de

...wäre hochgradig fahrlässig.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen und, abgesehen von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regel, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:43:44Z

Admin: /* Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

Beispiel: Der eigenen, von außen sichtbaren IP 78.123.234.45 wird vom DynDDS-Dienst die Domain <myhomeserver.dyndns.de> zugewiesen.
Einmal eingerichtet, wird der eigene Rechner antworten, wenn die Domain http://myhomeserver.dyndns.de in die Browser-Adressleiste einkopiert wird.

=== Motivation für einen Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar.
Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Kurz: Die öffentliche Erreichbarkeit des eigenen Servers über die ungesicherte Adresse...

* http://myhomeserver.dyndns.de

...ist fahrlässig.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen und, abgesehen von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regel, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:43:04Z

Admin: /* Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

Beispiel: Der eigenen, von außen sichtbaren IP 78.123.234.45 wird vom DynDDS-Dienst die Domain <myhomeserver.dyndns.de> zugewiesen.
Einmal eingerichtet, wird der eigene Rechner antworten, wenn die Domain http://myhomeserver.dyndns.de in die Browser-Adressleiste einkopiert wird.

=== Motivation für einen Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar.
Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.
Die öffentliche Erreichbarkeit des eigenen Servers über die ungesicherte Adresse...
* http://myhomeserver.dyndns.de
...ist fahrlässig.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen und, abgesehen von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regel, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:41:44Z

Admin: /* Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

Beispiel: Der eigenen, von außen sichtbaren IP 78.123.234.45 wird vom DynDDS-Dienst die Domain <myhomeserver.dyndns.de> zugewiesen.
Einmal eingerichtet, wird der eigene Rechner antworten, wenn die Domain http://myhomeserver.dyndns.de in die Browser-Adressleiste einkopiert wird.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar.
Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.
Die öffentliche Erreichbarkeit des eigenen Servers über die ungesicherte Adresse...
* http://myhomeserver.dyndns.de
...ist fahrlässig.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen und, abgesehen von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regel, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:33:14Z

Admin: /* Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.
Einmal eingerichtet,

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen und, abgesehen von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regel, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:31:54Z

Admin: /* Sicherheitshinweise */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen und, abgesehen von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regel, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:28:03Z

Admin: /* Die Kette von außen nach innen */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen und, abgesehen von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regeln, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:27:33Z

Admin: /* Die Kette von außen nach innen */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen, und, abgesehen von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regeln, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:26:53Z

Admin: /* Die Kette von außen nach innen */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen, und, jenseits von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regeln, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:23:03Z

Admin: /* Die Kette von außen nach innen */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man sicherlich darüber nachdenken, einen VPN-Tunnel einzurichten. Noch sicherer - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regeln, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:19:58Z

Admin: /* Die Kette von außen nach innen */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wäre das am sichersten über ein VPN zu realisieren. Sicherer - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regeln, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:18:44Z

Admin: /* Die Kette von außen nach innen */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wäre das am sichersten über ein VPN mit SSH/Zertifikat zu realisieren. Sicherer - und einfacher - ist es dennoch, die Administration ausschließlich über einen SSH-Zugang im inneren 192.168.-er-Netz zuzulassen.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regeln, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:10:07Z

Admin: /* Die Kette von außen nach innen */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS, 443 umgeleitet werden.

Die Idee, Port 80 ebenfalls dicht zu machen und ausschließlich HTTPS zuzulassen, liegt nahe, scheitert aber spätestens beim TLS-Zertifikat. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung der Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wäre das vermutlich am sichersten über ein VPN mit SSH/Zertifikat zu realisieren.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regeln, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:05:01Z

Admin: /* Sicherheitshinweise */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports 80/TCP und 443/TCP nach außen frei gibt. Sollte es nötig sein, den Server von außen zu administrieren, wäre das vermutlich am sichersten über ein VPN mit SSH/Zertifikat zu realisieren.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regeln, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T23:02:23Z

Admin: /* Sicherheitshinweise */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports 80/TCP und 443/TCP nach außen frei gibt. Sollte es nötig sein, den Server von außen zu administrieren, wäre das vermutlich am sichersten über ein VPN mit SSH/Zertifikat zu realisieren.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Wenn das nicht geht: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur 80 + 443)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

Abschließend eine absolute Regeln, die immer und durch die Ewigkeiten gilt:
* Dienste, die '''NICHT''' existieren, werden nicht angegriffen! Wenig ist hier immer mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T22:58:09Z

Admin: /* Die Kette von außen nach innen */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports 80/TCP und 443/TCP nach außen frei gibt. Sollte es nötig sein, den Server von außen zu administrieren, wäre das vermutlich am sichersten über ein VPN mit SSH/Zertifikat zu realisieren.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur 80 + 443)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T22:50:18Z

Admin: /* Die Kette von außen nach innen */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur 80 + 443)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T22:43:38Z

Admin: /* Annahmen / Szenario */

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur 80 + 443)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Homeserver-Sicherheitsarchitektur

2026-05-27T22:39:21Z

Admin: Die Seite wurde neu angelegt: „== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose == Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein. Es gibt verschiedene Anbieter, oft auch kostenlose. === Ein Leitfaden…“

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt verschiedene Anbieter, oft auch kostenlose.

=== Ein Leitfaden für selbst gehostete Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar. Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ: nginx, Apache, aber Caddy hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer aufgrund "zu vieler" Fehlversuche bei der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus nachvollziehen oder teilen können.)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
↓ Portweiterleitung: :80 + :443 → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://<wan-ip>:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig <wan-interface>
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig <lan-interface>
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep <PORT>

# Firewall-Regeln anzeigen:
pfctl -s rules | grep <PORT>

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i <wan-interface> port <PORT>

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i <lan-interface> port <PORT>
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via <falsche-gateway-ip> dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t <tabellenname> -T show | wc -l
pfctl -t <tabellenname> -T show | grep <IP>
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur 80 + 443)
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine externen Freigaben'''
* DHCP-Reservations per MAC-Adresse verhindern IP-Wechsel nach Neustarts
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren

----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''

Projekte

2026-05-27T22:16:54Z

Admin: /* Infrastruktur */

== Software ==
* [[ChatGPT-Client - Wiki]]
* [[Git-Spickzettel]]
* [[Mutt - ein textbasierter Mail-Client ]]

== Server-Administration ==

=== Sicherheit ===
* [[SSH]]

=== Webserver ===
* [[:Kategorie:Webserver|Webserver – Übersicht]]

=== Infrastruktur ===
* [[Homeserver-Sicherheitsarchitektur]]
* [[Powertop (Linux-Daemon)]]

== Romanprojekt: Der verborgene Bach ==
* [[Basis: Die "Kunst der Fuge", BWV 1080]]
* [[Plot]]

[[Kategorie:Projekte]]

Projekte

2026-05-27T22:06:14Z

Admin: /* Infrastruktur */

== Software ==
* [[ChatGPT-Client - Wiki]]
* [[Git-Spickzettel]]
* [[Mutt - ein textbasierter Mail-Client ]]

== Server-Administration ==

=== Sicherheit ===
* [[SSH]]

=== Webserver ===
* [[:Kategorie:Webserver|Webserver – Übersicht]]

=== Infrastruktur ===
* [[Netzwerkdiagnose]]
* [[Powertop (Linux-Daemon)]]

== Romanprojekt: Der verborgene Bach ==
* [[Basis: Die "Kunst der Fuge", BWV 1080]]
* [[Plot]]

[[Kategorie:Projekte]]

Robert Franz (1815-1892), deutscher Komponist

2026-05-27T13:50:58Z

Admin: /* Familie */

{{DISPLAYTITLE:Robert Franz}}
[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]
Robert Franz (eigentlich Robert Franz Julius Knauth; * 28. Juni 1815 in Halle an der Saale; † 24. Oktober 1892 ebenda) war ein deutscher Komponist, Organist und Dirigent. Zu Lebzeiten von Zeitgenossen wie Robert Schumann, Franz Liszt und Felix Mendelssohn geschätzt, gehört er heute zu den weitgehend vergessenen Komponisten der deutschen Romantik.

[[Datei:Robert Franz.jpg|thumb|right|250px|Robert Franz (1815–1892)]]

== Leben ==

=== Herkunft und Ausbildung ===

Robert Franz stammte aus einer alteingesessenen Hallorer-Familie. (Siehe auch: [[Halloren]]).
Er wuchs in Halle auf, wo er ab 1828 die Latina der Franckeschen Stiftungen besuchte. Früh fiel er durch musikalische Begabung auf; der dortige Kantor Carl Gottlob Abela ließ ihn die Proben des Schulchors am Klavier begleiten. Von 1835 bis 1837 studierte er Komposition bei Friedrich Schneider in Dessau und kehrte danach nach Halle zurück – in eine Stadt, die er zeit seines Lebens kaum verlassen sollte.

=== Berufliche Laufbahn in Halle ===

Nach schwierigen wirtschaftlichen Anfangsjahren übernahm Franz 1841 das Organistenamt an der Ulrichskirche. Im folgenden Jahr wurde er Dirigent der Singakademie Halle, die später seinen Namen annahm. 1848 heiratete er Marie Hinrichs, Tochter eines Professors und selbst Komponistin; das Paar hatte drei Kinder. 1859 wurde Franz schließlich zum Universitätsmusikdirektor ernannt – der Höhepunkt seiner öffentlichen Laufbahn.

=== Krankheit und Rückzug ===

Seit 1843 litt Franz an einem Nerven- und Ohrenleiden, das sich über Jahrzehnte progressiv verschlimmerte und schließlich zur vollständigen Taubheit führte. 1867 wurde er beurlaubt,
1868 musste er alle Ämter endgültig aufgeben. Die daraus folgende finanzielle Not war erheblich: Ein 1867 zuerkannter Ehrensold wurde ihm 1877 auf Betreiben von Widersachern wieder entzogen. Seinen Lebensunterhalt sicherte schließlich ein 1873 von Freunden und Kollegen – allen voran Franz Liszt – gestifteter Ehrenfonds in Höhe von 30.000 Talern.

Die letzten rund 25 Jahre seines Lebens verbrachte Franz in nahezu vollständiger Taubheit und sozialem Rückzug. Er starb am 24. Oktober 1892 in Halle.

1885 wurde ihm zu seinem 70. Geburtstag – anlässlich der Feier des 200. Geburtstags Georg Friedrich Händels – das Ehrenbürgerrecht der Stadt Halle verliehen.

=== Familie ===

1848 heiratete Robert Franz in Halle Marie Hinrichs (1828–1891),
Tochter des Hallenser Philosophieprofessors Hermann Friedrich
Wilhelm Hinrichs. Marie Franz war selbst Komponistin und hatte bereits 1846 – also
zwei Jahre vor der Heirat – bei Breitkopf & Härtel in Leipzig einen
Band mit neun Gesängen für Singstimme und Klavier veröffentlicht.

Dem Paar wurden drei Kinder geboren. Bekannt sind: ein Sohn, der
1900 als praktischer Arzt in Heidelberg starb, sowie eine Tochter,
die den Superintendenten Bethge in Giebichenstein heiratete.

Marie Franz starb 1891. Robert Franz,
taub und weitgehend isoliert, überlebte sie um ein Jahr.
Beide sind auf dem Stadtgottesacker in Halle begraben.

[[Datei:Robert-franz-im-alter.png |thumb|right|250px|Robert Franz, späte Aufnahme]]

== Das Werk ==

=== Die Lieder ===

Robert Franz schrieb über 350 Kunstlieder für Singstimme und Klavier – und fast ausschließlich das. Keine Symphonien, keine Opern, kein Streichquartett. Diese bewusste Konzentration auf eine einzige Gattung war seine Stärke und zugleich der Grund für sein späteres Vergessen.

Etwa ein Viertel seiner Lieder vertont Texte von Heinrich Heine. Daneben war Karl Wilhelm Osterwald ein bevorzugter Dichter. Franz' Vertonungsweise gilt als außerordentlich textgetreu und harmonisch differenziert – ohne Effekthascherei, in großer Zurückhaltung und mit feinem Klangsinn. Robert Schumann, dem Franz 1843 sein erstes gedrucktes Heft (op. 1, ''Zwölf Gesänge'') zuschickte, antwortete, die Lieder hätten ihm gefallen „wie seit langer Zeit keine mehr". Auch Mendelssohn, Liszt und Wagner äußerten sich anerkennend.

Zu den heute noch gelegentlich aufgeführten Liedern gehören:
* ''Aus meinen großen Schmerzen'', op. 5 Nr. 1 (Text: Heinrich Heine)
* ''Auf dem Meere'', op. 5 Nr. 3 (Text: Heinrich Heine)
* ''Sterne mit den goldnen Füßchen'' (Text: Heinrich Heine)
* ''Schilflieder'', op. 2 (Text: Nikolaus Lenau)

Die Opuszahlen von ''Sterne mit den goldnen Füßchen''
konnten nicht zweifelsfrei belegt werden.

=== Bearbeitungen von Bach und Händel ===

Neben seinen Liedern hat Franz einen – heute kaum noch bekannten,
aber musikhistorisch aufschlussreichen – Teil seiner Energie in die
Bearbeitung älterer Musik investiert. Als Leiter der Singakademie
musste er Werke von Bach und Händel aufführbar machen – und das
bedeutete im 19. Jahrhundert: eingreifen.

Konkret tat er dreierlei:

* '''Generalbassaussetzung:''' Die in Barockpartituren nur als bezifferter oder unbezifferter Bass notierten Begleitstimmen schrieb er vollständig aus – für Klavier oder Orchester.

* '''Uminstrumentierung:''' Barockbesetzungen ersetzte er durch das romantische Orchester. Cembalo, Gambe, Oboe d'amore – all das wurde durch zeitgenössische Instrumente ersetzt.

* '''Ergänzung fehlender Stimmen:''' Wo Partituren lückenhaft überliefert waren, schrieb er fehlende Stimmen hinzu.

Das Ergebnis war kein historisches Bach oder Händel, sondern Bach
und Händel im romantischen Gewand – aufführungspraktisch für das
19. Jahrhundert gedacht, ästhetisch aber von Anfang an umstritten.

Genau hier lag der Kern des späteren Streits mit Friedrich
Chrysander und Philipp Spitta (siehe [[#Der Bearbeitungsstreit|
Der Bearbeitungsstreit]]): nicht ob man den Generalbass aussetzen
darf, sondern ''wie'' – und ob dabei die Klangsprache des
19. Jahrhunderts legitim ist.

== Der Bearbeitungsstreit ==

Franz' Ergänzungen des barocken Generalbasssatzes – also seine Ausführung der in Barockpartituren nur skizzenhaft notierten Begleitung – stießen auf scharfen Widerspruch der aufkommenden philologisch-historischen Schule. Besonders Friedrich Chrysander, Herausgeber der Händel-Gesamtausgabe, und Philipp Spitta, der maßgebliche Bach-Forscher der Zeit, kritisierten Franz' Herangehensweise als zu romantisierend und zu wenig historisch korrekt.

Franz seinerseits ließ sich das nicht gefallen. In einem [[Brief vom 1. Februar 1871 | Brief]] an seinen Freund Julius Schäffer schrieb er über Chrysander:

: ''„Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne gepachtet zu haben."''

Der Streit wurde auch öffentlich geführt. Schäffer verfasste zwischen 1875 und 1880 eine Reihe von Streitschriften zur Verteidigung der Franz'schen Bearbeitungen, darunter ''Entgegnung auf Ph. Spitta's Artikel: Über das Accompagnement in den Kompositionen Seb. Bachs'' und ''Friedr. Chrysander in seinen Klavierauszügen zur deutschen Händel-Ausgabe''. Franz selbst meldete sich mit einem ''Offenen Brief an Eduard Hanslick'' und den ''Mitteilungen über J. S. Bachs Magnificat'' zu Wort.

Auf Seiten der Franz'schen Bearbeitungen standen namhafte Praktiker wie Liszt, Felix Mottl, Hans Richter und Arthur Nikisch. Die philologische Schule – Chrysander, Spitta – pochte auf Texttreue.

Dieser Streit ist im Kern derselbe, der bis heute nicht wirklich entschieden ist: Wie viel interpretatorische Freiheit darf – oder muss – eine lebendige Aufführung alter Musik haben? Franz stand auf der Seite der musikalischen Praxis; die Gegenseite bereitete den Boden für das vor, was später als Historisch Informierte Aufführungspraxis bekannt werden sollte.

== Warum ist Robert Franz vergessen? ==

Das ist eine berechtigte Frage – und die Antwort ist vielschichtig:

* '''Das Gattungsproblem:''' Franz schrieb fast ausschließlich Lieder. Im 20. Jahrhundert rückte das Kunstlied zunehmend an den Rand des Konzertlebens. Komponisten, die auch Symphonien, Kammermusik oder größere Vokalwerke hinterlassen haben – Brahms, Schumann, Schubert –, blieben im Repertoire präsent. Franz nicht.

* '''Kein zyklisches Hauptwerk:''' Anders als Schubert mit der ''Winterreise'' oder der ''Schönen Müllerin'' hinterließ Franz keinen Liederzyklus, der als geschlossenes Abendprogramm funktioniert und vermarktbar ist.

* '''Kein überregionales Netzwerk:''' Franz lebte und arbeitete sein Leben lang in Halle. Er hatte keine Schüler, die seine Tradition weitergetragen hätten, und keine Präsenz in den großen Musikzentren Wien, Leipzig oder Berlin.

* '''Die Taubheit:''' 25 Jahre Isolation am Ende seines Lebens bedeuteten: kein Spätwerk, keine Weiterentwicklung, keine späten Meisterwerke wie bei Beethoven oder Schubert.

Schumann hatte Franz übrigens bereits früh ermahnt, sich nicht auf das Lied zu beschränken. Franz blieb trotzdem bei seiner Wahl – konsequent und ohne Kompromisse.

== Zeitgenössische Wertschätzung ==

Dass Franz zu Lebzeiten keineswegs unbekannt war, zeigt eine Episode aus dem Jahr 1873: Als seine finanzielle Lage nach dem Verlust seiner Ämter und Bezüge prekär wurde, organisierten Franz Liszt und andere namhafte Musikerpersönlichkeiten einen Ehrenfonds, der Franz den Lebensunterhalt sicherte. Liszt hatte zudem bereits 1872 eine Monographie über Franz verfasst.

== Weblinks und Quellen ==

* [https://www.deutsche-biographie.de/sfz16975.html Deutsche Biographie – Robert Franz] (Allgemeine Deutsche Biographie, Band 48, 1904)
* [https://de.wikipedia.org/wiki/Robert_Franz Wikipedia – Robert Franz]
* [https://www.musikland-sachsenanhalt.de/beitraege/franz-robert-1815-1892/ Musikland Sachsen-Anhalt – Robert Franz]
* [https://halle.de/kultur-tourismus/stadtgeschichte/bekannte-persoenlichkeiten/beruehmte-hallenser/details/franz-robert Berühmte Hallenser – Stadt Halle]
* [https://st.museum-digital.de/object/1102 Brief von Robert Franz an Julius Schäffer, 1. Februar 1871] – Stiftung Händel-Haus Halle (museum-digital Sachsen-Anhalt)
* [https://www.klassik-heute.com/4daction/www_komponist?id=43036&bio= Klassik Heute – Biographie Robert Franz]

----
''Seite erstellt im Kontext eines Konzertprogramms mit Liedern von Robert Franz, Mai 2026.''

Robert Franz (1815-1892), deutscher Komponist

2026-05-27T13:12:03Z

Admin: /* Bearbeitungen von Bach und Händel */

{{DISPLAYTITLE:Robert Franz}}
[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]
Robert Franz (eigentlich Robert Franz Julius Knauth; * 28. Juni 1815 in Halle an der Saale; † 24. Oktober 1892 ebenda) war ein deutscher Komponist, Organist und Dirigent. Zu Lebzeiten von Zeitgenossen wie Robert Schumann, Franz Liszt und Felix Mendelssohn geschätzt, gehört er heute zu den weitgehend vergessenen Komponisten der deutschen Romantik.

[[Datei:Robert Franz.jpg|thumb|right|250px|Robert Franz (1815–1892)]]

== Leben ==

=== Herkunft und Ausbildung ===

Robert Franz stammte aus einer alteingesessenen Hallorer-Familie. (Siehe auch: [[Halloren]]).
Er wuchs in Halle auf, wo er ab 1828 die Latina der Franckeschen Stiftungen besuchte. Früh fiel er durch musikalische Begabung auf; der dortige Kantor Carl Gottlob Abela ließ ihn die Proben des Schulchors am Klavier begleiten. Von 1835 bis 1837 studierte er Komposition bei Friedrich Schneider in Dessau und kehrte danach nach Halle zurück – in eine Stadt, die er zeit seines Lebens kaum verlassen sollte.

=== Berufliche Laufbahn in Halle ===

Nach schwierigen wirtschaftlichen Anfangsjahren übernahm Franz 1841 das Organistenamt an der Ulrichskirche. Im folgenden Jahr wurde er Dirigent der Singakademie Halle, die später seinen Namen annahm. 1848 heiratete er Marie Hinrichs, Tochter eines Professors und selbst Komponistin; das Paar hatte drei Kinder. 1859 wurde Franz schließlich zum Universitätsmusikdirektor ernannt – der Höhepunkt seiner öffentlichen Laufbahn.

=== Krankheit und Rückzug ===

Seit 1843 litt Franz an einem Nerven- und Ohrenleiden, das sich über Jahrzehnte progressiv verschlimmerte und schließlich zur vollständigen Taubheit führte. 1867 wurde er beurlaubt,
1868 musste er alle Ämter endgültig aufgeben. Die daraus folgende finanzielle Not war erheblich: Ein 1867 zuerkannter Ehrensold wurde ihm 1877 auf Betreiben von Widersachern wieder entzogen. Seinen Lebensunterhalt sicherte schließlich ein 1873 von Freunden und Kollegen – allen voran Franz Liszt – gestifteter Ehrenfonds in Höhe von 30.000 Talern.

Die letzten rund 25 Jahre seines Lebens verbrachte Franz in nahezu vollständiger Taubheit und sozialem Rückzug. Er starb am 24. Oktober 1892 in Halle.

1885 wurde ihm zu seinem 70. Geburtstag – anlässlich der Feier des 200. Geburtstags Georg Friedrich Händels – das Ehrenbürgerrecht der Stadt Halle verliehen.

=== Familie ===

1848 heiratete Robert Franz in Halle Marie Hinrichs (1828–1891),
Tochter des Hallenser Philosophieprofessors Hermann Friedrich
Wilhelm Hinrichs. Marie Franz war selbst Komponistin und hatte bereits 1846 – also
zwei Jahre vor der Heirat – bei Breitkopf & Härtel in Leipzig einen
Band mit neun Gesängen für Singstimme und Klavier veröffentlicht.

Dem Paar wurden drei Kinder geboren. Bekannt sind: ein Sohn, der
1900 als praktischer Arzt in Heidelberg starb, sowie eine Tochter,
die den Superintendenten Bethge in Giebichenstein heiratete.

Marie Franz starb 1891 – ein Jahr vor ihrem Mann. Robert Franz,
taub und weitgehend isoliert, überlebte sie nur um ein Jahr.
Beide sind auf dem Stadtgottesacker in Halle begraben.

[[Datei:Robert-franz-im-alter.png |thumb|right|250px|Robert Franz, späte Aufnahme]]

== Das Werk ==

=== Die Lieder ===

Robert Franz schrieb über 350 Kunstlieder für Singstimme und Klavier – und fast ausschließlich das. Keine Symphonien, keine Opern, kein Streichquartett. Diese bewusste Konzentration auf eine einzige Gattung war seine Stärke und zugleich der Grund für sein späteres Vergessen.

Etwa ein Viertel seiner Lieder vertont Texte von Heinrich Heine. Daneben war Karl Wilhelm Osterwald ein bevorzugter Dichter. Franz' Vertonungsweise gilt als außerordentlich textgetreu und harmonisch differenziert – ohne Effekthascherei, in großer Zurückhaltung und mit feinem Klangsinn. Robert Schumann, dem Franz 1843 sein erstes gedrucktes Heft (op. 1, ''Zwölf Gesänge'') zuschickte, antwortete, die Lieder hätten ihm gefallen „wie seit langer Zeit keine mehr". Auch Mendelssohn, Liszt und Wagner äußerten sich anerkennend.

Zu den heute noch gelegentlich aufgeführten Liedern gehören:
* ''Aus meinen großen Schmerzen'', op. 5 Nr. 1 (Text: Heinrich Heine)
* ''Auf dem Meere'', op. 5 Nr. 3 (Text: Heinrich Heine)
* ''Sterne mit den goldnen Füßchen'' (Text: Heinrich Heine)
* ''Schilflieder'', op. 2 (Text: Nikolaus Lenau)

Die Opuszahlen von ''Sterne mit den goldnen Füßchen''
konnten nicht zweifelsfrei belegt werden.

=== Bearbeitungen von Bach und Händel ===

Neben seinen Liedern hat Franz einen – heute kaum noch bekannten,
aber musikhistorisch aufschlussreichen – Teil seiner Energie in die
Bearbeitung älterer Musik investiert. Als Leiter der Singakademie
musste er Werke von Bach und Händel aufführbar machen – und das
bedeutete im 19. Jahrhundert: eingreifen.

Konkret tat er dreierlei:

* '''Generalbassaussetzung:''' Die in Barockpartituren nur als bezifferter oder unbezifferter Bass notierten Begleitstimmen schrieb er vollständig aus – für Klavier oder Orchester.

* '''Uminstrumentierung:''' Barockbesetzungen ersetzte er durch das romantische Orchester. Cembalo, Gambe, Oboe d'amore – all das wurde durch zeitgenössische Instrumente ersetzt.

* '''Ergänzung fehlender Stimmen:''' Wo Partituren lückenhaft überliefert waren, schrieb er fehlende Stimmen hinzu.

Das Ergebnis war kein historisches Bach oder Händel, sondern Bach
und Händel im romantischen Gewand – aufführungspraktisch für das
19. Jahrhundert gedacht, ästhetisch aber von Anfang an umstritten.

Genau hier lag der Kern des späteren Streits mit Friedrich
Chrysander und Philipp Spitta (siehe [[#Der Bearbeitungsstreit|
Der Bearbeitungsstreit]]): nicht ob man den Generalbass aussetzen
darf, sondern ''wie'' – und ob dabei die Klangsprache des
19. Jahrhunderts legitim ist.

== Der Bearbeitungsstreit ==

Franz' Ergänzungen des barocken Generalbasssatzes – also seine Ausführung der in Barockpartituren nur skizzenhaft notierten Begleitung – stießen auf scharfen Widerspruch der aufkommenden philologisch-historischen Schule. Besonders Friedrich Chrysander, Herausgeber der Händel-Gesamtausgabe, und Philipp Spitta, der maßgebliche Bach-Forscher der Zeit, kritisierten Franz' Herangehensweise als zu romantisierend und zu wenig historisch korrekt.

Franz seinerseits ließ sich das nicht gefallen. In einem [[Brief vom 1. Februar 1871 | Brief]] an seinen Freund Julius Schäffer schrieb er über Chrysander:

: ''„Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne gepachtet zu haben."''

Der Streit wurde auch öffentlich geführt. Schäffer verfasste zwischen 1875 und 1880 eine Reihe von Streitschriften zur Verteidigung der Franz'schen Bearbeitungen, darunter ''Entgegnung auf Ph. Spitta's Artikel: Über das Accompagnement in den Kompositionen Seb. Bachs'' und ''Friedr. Chrysander in seinen Klavierauszügen zur deutschen Händel-Ausgabe''. Franz selbst meldete sich mit einem ''Offenen Brief an Eduard Hanslick'' und den ''Mitteilungen über J. S. Bachs Magnificat'' zu Wort.

Auf Seiten der Franz'schen Bearbeitungen standen namhafte Praktiker wie Liszt, Felix Mottl, Hans Richter und Arthur Nikisch. Die philologische Schule – Chrysander, Spitta – pochte auf Texttreue.

Dieser Streit ist im Kern derselbe, der bis heute nicht wirklich entschieden ist: Wie viel interpretatorische Freiheit darf – oder muss – eine lebendige Aufführung alter Musik haben? Franz stand auf der Seite der musikalischen Praxis; die Gegenseite bereitete den Boden für das vor, was später als Historisch Informierte Aufführungspraxis bekannt werden sollte.

== Warum ist Robert Franz vergessen? ==

Das ist eine berechtigte Frage – und die Antwort ist vielschichtig:

* '''Das Gattungsproblem:''' Franz schrieb fast ausschließlich Lieder. Im 20. Jahrhundert rückte das Kunstlied zunehmend an den Rand des Konzertlebens. Komponisten, die auch Symphonien, Kammermusik oder größere Vokalwerke hinterlassen haben – Brahms, Schumann, Schubert –, blieben im Repertoire präsent. Franz nicht.

* '''Kein zyklisches Hauptwerk:''' Anders als Schubert mit der ''Winterreise'' oder der ''Schönen Müllerin'' hinterließ Franz keinen Liederzyklus, der als geschlossenes Abendprogramm funktioniert und vermarktbar ist.

* '''Kein überregionales Netzwerk:''' Franz lebte und arbeitete sein Leben lang in Halle. Er hatte keine Schüler, die seine Tradition weitergetragen hätten, und keine Präsenz in den großen Musikzentren Wien, Leipzig oder Berlin.

* '''Die Taubheit:''' 25 Jahre Isolation am Ende seines Lebens bedeuteten: kein Spätwerk, keine Weiterentwicklung, keine späten Meisterwerke wie bei Beethoven oder Schubert.

Schumann hatte Franz übrigens bereits früh ermahnt, sich nicht auf das Lied zu beschränken. Franz blieb trotzdem bei seiner Wahl – konsequent und ohne Kompromisse.

== Zeitgenössische Wertschätzung ==

Dass Franz zu Lebzeiten keineswegs unbekannt war, zeigt eine Episode aus dem Jahr 1873: Als seine finanzielle Lage nach dem Verlust seiner Ämter und Bezüge prekär wurde, organisierten Franz Liszt und andere namhafte Musikerpersönlichkeiten einen Ehrenfonds, der Franz den Lebensunterhalt sicherte. Liszt hatte zudem bereits 1872 eine Monographie über Franz verfasst.

== Weblinks und Quellen ==

* [https://www.deutsche-biographie.de/sfz16975.html Deutsche Biographie – Robert Franz] (Allgemeine Deutsche Biographie, Band 48, 1904)
* [https://de.wikipedia.org/wiki/Robert_Franz Wikipedia – Robert Franz]
* [https://www.musikland-sachsenanhalt.de/beitraege/franz-robert-1815-1892/ Musikland Sachsen-Anhalt – Robert Franz]
* [https://halle.de/kultur-tourismus/stadtgeschichte/bekannte-persoenlichkeiten/beruehmte-hallenser/details/franz-robert Berühmte Hallenser – Stadt Halle]
* [https://st.museum-digital.de/object/1102 Brief von Robert Franz an Julius Schäffer, 1. Februar 1871] – Stiftung Händel-Haus Halle (museum-digital Sachsen-Anhalt)
* [https://www.klassik-heute.com/4daction/www_komponist?id=43036&bio= Klassik Heute – Biographie Robert Franz]

----
''Seite erstellt im Kontext eines Konzertprogramms mit Liedern von Robert Franz, Mai 2026.''

Robert Franz (1815-1892), deutscher Komponist

2026-05-27T13:10:42Z

Admin: /* Warum ist Robert Franz vergessen? */

{{DISPLAYTITLE:Robert Franz}}
[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]
Robert Franz (eigentlich Robert Franz Julius Knauth; * 28. Juni 1815 in Halle an der Saale; † 24. Oktober 1892 ebenda) war ein deutscher Komponist, Organist und Dirigent. Zu Lebzeiten von Zeitgenossen wie Robert Schumann, Franz Liszt und Felix Mendelssohn geschätzt, gehört er heute zu den weitgehend vergessenen Komponisten der deutschen Romantik.

[[Datei:Robert Franz.jpg|thumb|right|250px|Robert Franz (1815–1892)]]

== Leben ==

=== Herkunft und Ausbildung ===

Robert Franz stammte aus einer alteingesessenen Hallorer-Familie. (Siehe auch: [[Halloren]]).
Er wuchs in Halle auf, wo er ab 1828 die Latina der Franckeschen Stiftungen besuchte. Früh fiel er durch musikalische Begabung auf; der dortige Kantor Carl Gottlob Abela ließ ihn die Proben des Schulchors am Klavier begleiten. Von 1835 bis 1837 studierte er Komposition bei Friedrich Schneider in Dessau und kehrte danach nach Halle zurück – in eine Stadt, die er zeit seines Lebens kaum verlassen sollte.

=== Berufliche Laufbahn in Halle ===

Nach schwierigen wirtschaftlichen Anfangsjahren übernahm Franz 1841 das Organistenamt an der Ulrichskirche. Im folgenden Jahr wurde er Dirigent der Singakademie Halle, die später seinen Namen annahm. 1848 heiratete er Marie Hinrichs, Tochter eines Professors und selbst Komponistin; das Paar hatte drei Kinder. 1859 wurde Franz schließlich zum Universitätsmusikdirektor ernannt – der Höhepunkt seiner öffentlichen Laufbahn.

=== Krankheit und Rückzug ===

Seit 1843 litt Franz an einem Nerven- und Ohrenleiden, das sich über Jahrzehnte progressiv verschlimmerte und schließlich zur vollständigen Taubheit führte. 1867 wurde er beurlaubt,
1868 musste er alle Ämter endgültig aufgeben. Die daraus folgende finanzielle Not war erheblich: Ein 1867 zuerkannter Ehrensold wurde ihm 1877 auf Betreiben von Widersachern wieder entzogen. Seinen Lebensunterhalt sicherte schließlich ein 1873 von Freunden und Kollegen – allen voran Franz Liszt – gestifteter Ehrenfonds in Höhe von 30.000 Talern.

Die letzten rund 25 Jahre seines Lebens verbrachte Franz in nahezu vollständiger Taubheit und sozialem Rückzug. Er starb am 24. Oktober 1892 in Halle.

1885 wurde ihm zu seinem 70. Geburtstag – anlässlich der Feier des 200. Geburtstags Georg Friedrich Händels – das Ehrenbürgerrecht der Stadt Halle verliehen.

=== Familie ===

1848 heiratete Robert Franz in Halle Marie Hinrichs (1828–1891),
Tochter des Hallenser Philosophieprofessors Hermann Friedrich
Wilhelm Hinrichs. Marie Franz war selbst Komponistin und hatte bereits 1846 – also
zwei Jahre vor der Heirat – bei Breitkopf & Härtel in Leipzig einen
Band mit neun Gesängen für Singstimme und Klavier veröffentlicht.

Dem Paar wurden drei Kinder geboren. Bekannt sind: ein Sohn, der
1900 als praktischer Arzt in Heidelberg starb, sowie eine Tochter,
die den Superintendenten Bethge in Giebichenstein heiratete.

Marie Franz starb 1891 – ein Jahr vor ihrem Mann. Robert Franz,
taub und weitgehend isoliert, überlebte sie nur um ein Jahr.
Beide sind auf dem Stadtgottesacker in Halle begraben.

[[Datei:Robert-franz-im-alter.png |thumb|right|250px|Robert Franz, späte Aufnahme]]

== Das Werk ==

=== Die Lieder ===

Robert Franz schrieb über 350 Kunstlieder für Singstimme und Klavier – und fast ausschließlich das. Keine Symphonien, keine Opern, kein Streichquartett. Diese bewusste Konzentration auf eine einzige Gattung war seine Stärke und zugleich der Grund für sein späteres Vergessen.

Etwa ein Viertel seiner Lieder vertont Texte von Heinrich Heine. Daneben war Karl Wilhelm Osterwald ein bevorzugter Dichter. Franz' Vertonungsweise gilt als außerordentlich textgetreu und harmonisch differenziert – ohne Effekthascherei, in großer Zurückhaltung und mit feinem Klangsinn. Robert Schumann, dem Franz 1843 sein erstes gedrucktes Heft (op. 1, ''Zwölf Gesänge'') zuschickte, antwortete, die Lieder hätten ihm gefallen „wie seit langer Zeit keine mehr". Auch Mendelssohn, Liszt und Wagner äußerten sich anerkennend.

Zu den heute noch gelegentlich aufgeführten Liedern gehören:
* ''Aus meinen großen Schmerzen'', op. 5 Nr. 1 (Text: Heinrich Heine)
* ''Auf dem Meere'', op. 5 Nr. 3 (Text: Heinrich Heine)
* ''Sterne mit den goldnen Füßchen'' (Text: Heinrich Heine)
* ''Schilflieder'', op. 2 (Text: Nikolaus Lenau)

Die Opuszahlen von ''Sterne mit den goldnen Füßchen''
konnten nicht zweifelsfrei belegt werden.

=== Bearbeitungen von Bach und Händel ===

Neben seinen Liedern hat Franz einen – heute kaum noch bekannten,
aber musikhistorisch aufschlussreichen – Teil seiner Energie in die
Bearbeitung älterer Musik investiert. Als Leiter der Singakademie
musste er Werke von Bach und Händel aufführbar machen – und das
bedeutete im 19. Jahrhundert: eingreifen.

Konkret tat er dreierlei:

* '''Generalbassaussetzung:''' Die in Barockpartituren nur als
bezifferter oder unbezifferter Bass notierten Begleitstimmen
schrieb er vollständig aus – für Klavier oder Orchester.

* '''Uminstrumentierung:''' Barockbesetzungen ersetzte er durch
das romantische Orchester. Cembalo, Gambe, Oboe d'amore –
all das wurde durch zeitgenössische Instrumente ersetzt.

* '''Ergänzung fehlender Stimmen:''' Wo Partituren lückenhaft
überliefert waren, schrieb er fehlende Stimmen hinzu.

Das Ergebnis war kein historisches Bach oder Händel, sondern Bach
und Händel im romantischen Gewand – aufführungspraktisch für das
19. Jahrhundert gedacht, ästhetisch aber von Anfang an umstritten.

Genau hier lag der Kern des späteren Streits mit Friedrich
Chrysander und Philipp Spitta (siehe [[#Der Bearbeitungsstreit|
Der Bearbeitungsstreit]]): nicht ob man den Generalbass aussetzen
darf, sondern ''wie'' – und ob dabei die Klangsprache des
19. Jahrhunderts legitim ist.

== Der Bearbeitungsstreit ==

Franz' Ergänzungen des barocken Generalbasssatzes – also seine Ausführung der in Barockpartituren nur skizzenhaft notierten Begleitung – stießen auf scharfen Widerspruch der aufkommenden philologisch-historischen Schule. Besonders Friedrich Chrysander, Herausgeber der Händel-Gesamtausgabe, und Philipp Spitta, der maßgebliche Bach-Forscher der Zeit, kritisierten Franz' Herangehensweise als zu romantisierend und zu wenig historisch korrekt.

Franz seinerseits ließ sich das nicht gefallen. In einem [[Brief vom 1. Februar 1871 | Brief]] an seinen Freund Julius Schäffer schrieb er über Chrysander:

: ''„Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne gepachtet zu haben."''

Der Streit wurde auch öffentlich geführt. Schäffer verfasste zwischen 1875 und 1880 eine Reihe von Streitschriften zur Verteidigung der Franz'schen Bearbeitungen, darunter ''Entgegnung auf Ph. Spitta's Artikel: Über das Accompagnement in den Kompositionen Seb. Bachs'' und ''Friedr. Chrysander in seinen Klavierauszügen zur deutschen Händel-Ausgabe''. Franz selbst meldete sich mit einem ''Offenen Brief an Eduard Hanslick'' und den ''Mitteilungen über J. S. Bachs Magnificat'' zu Wort.

Auf Seiten der Franz'schen Bearbeitungen standen namhafte Praktiker wie Liszt, Felix Mottl, Hans Richter und Arthur Nikisch. Die philologische Schule – Chrysander, Spitta – pochte auf Texttreue.

Dieser Streit ist im Kern derselbe, der bis heute nicht wirklich entschieden ist: Wie viel interpretatorische Freiheit darf – oder muss – eine lebendige Aufführung alter Musik haben? Franz stand auf der Seite der musikalischen Praxis; die Gegenseite bereitete den Boden für das vor, was später als Historisch Informierte Aufführungspraxis bekannt werden sollte.

== Warum ist Robert Franz vergessen? ==

Das ist eine berechtigte Frage – und die Antwort ist vielschichtig:

* '''Das Gattungsproblem:''' Franz schrieb fast ausschließlich Lieder. Im 20. Jahrhundert rückte das Kunstlied zunehmend an den Rand des Konzertlebens. Komponisten, die auch Symphonien, Kammermusik oder größere Vokalwerke hinterlassen haben – Brahms, Schumann, Schubert –, blieben im Repertoire präsent. Franz nicht.

* '''Kein zyklisches Hauptwerk:''' Anders als Schubert mit der ''Winterreise'' oder der ''Schönen Müllerin'' hinterließ Franz keinen Liederzyklus, der als geschlossenes Abendprogramm funktioniert und vermarktbar ist.

* '''Kein überregionales Netzwerk:''' Franz lebte und arbeitete sein Leben lang in Halle. Er hatte keine Schüler, die seine Tradition weitergetragen hätten, und keine Präsenz in den großen Musikzentren Wien, Leipzig oder Berlin.

* '''Die Taubheit:''' 25 Jahre Isolation am Ende seines Lebens bedeuteten: kein Spätwerk, keine Weiterentwicklung, keine späten Meisterwerke wie bei Beethoven oder Schubert.

Schumann hatte Franz übrigens bereits früh ermahnt, sich nicht auf das Lied zu beschränken. Franz blieb trotzdem bei seiner Wahl – konsequent und ohne Kompromisse.

== Zeitgenössische Wertschätzung ==

Dass Franz zu Lebzeiten keineswegs unbekannt war, zeigt eine Episode aus dem Jahr 1873: Als seine finanzielle Lage nach dem Verlust seiner Ämter und Bezüge prekär wurde, organisierten Franz Liszt und andere namhafte Musikerpersönlichkeiten einen Ehrenfonds, der Franz den Lebensunterhalt sicherte. Liszt hatte zudem bereits 1872 eine Monographie über Franz verfasst.

== Weblinks und Quellen ==

* [https://www.deutsche-biographie.de/sfz16975.html Deutsche Biographie – Robert Franz] (Allgemeine Deutsche Biographie, Band 48, 1904)
* [https://de.wikipedia.org/wiki/Robert_Franz Wikipedia – Robert Franz]
* [https://www.musikland-sachsenanhalt.de/beitraege/franz-robert-1815-1892/ Musikland Sachsen-Anhalt – Robert Franz]
* [https://halle.de/kultur-tourismus/stadtgeschichte/bekannte-persoenlichkeiten/beruehmte-hallenser/details/franz-robert Berühmte Hallenser – Stadt Halle]
* [https://st.museum-digital.de/object/1102 Brief von Robert Franz an Julius Schäffer, 1. Februar 1871] – Stiftung Händel-Haus Halle (museum-digital Sachsen-Anhalt)
* [https://www.klassik-heute.com/4daction/www_komponist?id=43036&bio= Klassik Heute – Biographie Robert Franz]

----
''Seite erstellt im Kontext eines Konzertprogramms mit Liedern von Robert Franz, Mai 2026.''

Robert Franz (1815-1892), deutscher Komponist

2026-05-27T13:09:01Z

Admin: /* Bearbeitungen von Bach und Händel */

{{DISPLAYTITLE:Robert Franz}}
[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]
Robert Franz (eigentlich Robert Franz Julius Knauth; * 28. Juni 1815 in Halle an der Saale; † 24. Oktober 1892 ebenda) war ein deutscher Komponist, Organist und Dirigent. Zu Lebzeiten von Zeitgenossen wie Robert Schumann, Franz Liszt und Felix Mendelssohn geschätzt, gehört er heute zu den weitgehend vergessenen Komponisten der deutschen Romantik.

[[Datei:Robert Franz.jpg|thumb|right|250px|Robert Franz (1815–1892)]]

== Leben ==

=== Herkunft und Ausbildung ===

Robert Franz stammte aus einer alteingesessenen Hallorer-Familie. (Siehe auch: [[Halloren]]).
Er wuchs in Halle auf, wo er ab 1828 die Latina der Franckeschen Stiftungen besuchte. Früh fiel er durch musikalische Begabung auf; der dortige Kantor Carl Gottlob Abela ließ ihn die Proben des Schulchors am Klavier begleiten. Von 1835 bis 1837 studierte er Komposition bei Friedrich Schneider in Dessau und kehrte danach nach Halle zurück – in eine Stadt, die er zeit seines Lebens kaum verlassen sollte.

=== Berufliche Laufbahn in Halle ===

Nach schwierigen wirtschaftlichen Anfangsjahren übernahm Franz 1841 das Organistenamt an der Ulrichskirche. Im folgenden Jahr wurde er Dirigent der Singakademie Halle, die später seinen Namen annahm. 1848 heiratete er Marie Hinrichs, Tochter eines Professors und selbst Komponistin; das Paar hatte drei Kinder. 1859 wurde Franz schließlich zum Universitätsmusikdirektor ernannt – der Höhepunkt seiner öffentlichen Laufbahn.

=== Krankheit und Rückzug ===

Seit 1843 litt Franz an einem Nerven- und Ohrenleiden, das sich über Jahrzehnte progressiv verschlimmerte und schließlich zur vollständigen Taubheit führte. 1867 wurde er beurlaubt,
1868 musste er alle Ämter endgültig aufgeben. Die daraus folgende finanzielle Not war erheblich: Ein 1867 zuerkannter Ehrensold wurde ihm 1877 auf Betreiben von Widersachern wieder entzogen. Seinen Lebensunterhalt sicherte schließlich ein 1873 von Freunden und Kollegen – allen voran Franz Liszt – gestifteter Ehrenfonds in Höhe von 30.000 Talern.

Die letzten rund 25 Jahre seines Lebens verbrachte Franz in nahezu vollständiger Taubheit und sozialem Rückzug. Er starb am 24. Oktober 1892 in Halle.

1885 wurde ihm zu seinem 70. Geburtstag – anlässlich der Feier des 200. Geburtstags Georg Friedrich Händels – das Ehrenbürgerrecht der Stadt Halle verliehen.

=== Familie ===

1848 heiratete Robert Franz in Halle Marie Hinrichs (1828–1891),
Tochter des Hallenser Philosophieprofessors Hermann Friedrich
Wilhelm Hinrichs. Marie Franz war selbst Komponistin und hatte bereits 1846 – also
zwei Jahre vor der Heirat – bei Breitkopf & Härtel in Leipzig einen
Band mit neun Gesängen für Singstimme und Klavier veröffentlicht.

Dem Paar wurden drei Kinder geboren. Bekannt sind: ein Sohn, der
1900 als praktischer Arzt in Heidelberg starb, sowie eine Tochter,
die den Superintendenten Bethge in Giebichenstein heiratete.

Marie Franz starb 1891 – ein Jahr vor ihrem Mann. Robert Franz,
taub und weitgehend isoliert, überlebte sie nur um ein Jahr.
Beide sind auf dem Stadtgottesacker in Halle begraben.

[[Datei:Robert-franz-im-alter.png |thumb|right|250px|Robert Franz, späte Aufnahme]]

== Das Werk ==

=== Die Lieder ===

Robert Franz schrieb über 350 Kunstlieder für Singstimme und Klavier – und fast ausschließlich das. Keine Symphonien, keine Opern, kein Streichquartett. Diese bewusste Konzentration auf eine einzige Gattung war seine Stärke und zugleich der Grund für sein späteres Vergessen.

Etwa ein Viertel seiner Lieder vertont Texte von Heinrich Heine. Daneben war Karl Wilhelm Osterwald ein bevorzugter Dichter. Franz' Vertonungsweise gilt als außerordentlich textgetreu und harmonisch differenziert – ohne Effekthascherei, in großer Zurückhaltung und mit feinem Klangsinn. Robert Schumann, dem Franz 1843 sein erstes gedrucktes Heft (op. 1, ''Zwölf Gesänge'') zuschickte, antwortete, die Lieder hätten ihm gefallen „wie seit langer Zeit keine mehr". Auch Mendelssohn, Liszt und Wagner äußerten sich anerkennend.

Zu den heute noch gelegentlich aufgeführten Liedern gehören:
* ''Aus meinen großen Schmerzen'', op. 5 Nr. 1 (Text: Heinrich Heine)
* ''Auf dem Meere'', op. 5 Nr. 3 (Text: Heinrich Heine)
* ''Sterne mit den goldnen Füßchen'' (Text: Heinrich Heine)
* ''Schilflieder'', op. 2 (Text: Nikolaus Lenau)

Die Opuszahlen von ''Sterne mit den goldnen Füßchen''
konnten nicht zweifelsfrei belegt werden.

=== Bearbeitungen von Bach und Händel ===

Neben seinen Liedern hat Franz einen – heute kaum noch bekannten,
aber musikhistorisch aufschlussreichen – Teil seiner Energie in die
Bearbeitung älterer Musik investiert. Als Leiter der Singakademie
musste er Werke von Bach und Händel aufführbar machen – und das
bedeutete im 19. Jahrhundert: eingreifen.

Konkret tat er dreierlei:

* '''Generalbassaussetzung:''' Die in Barockpartituren nur als
bezifferter oder unbezifferter Bass notierten Begleitstimmen
schrieb er vollständig aus – für Klavier oder Orchester.

* '''Uminstrumentierung:''' Barockbesetzungen ersetzte er durch
das romantische Orchester. Cembalo, Gambe, Oboe d'amore –
all das wurde durch zeitgenössische Instrumente ersetzt.

* '''Ergänzung fehlender Stimmen:''' Wo Partituren lückenhaft
überliefert waren, schrieb er fehlende Stimmen hinzu.

Das Ergebnis war kein historisches Bach oder Händel, sondern Bach
und Händel im romantischen Gewand – aufführungspraktisch für das
19. Jahrhundert gedacht, ästhetisch aber von Anfang an umstritten.

Genau hier lag der Kern des späteren Streits mit Friedrich
Chrysander und Philipp Spitta (siehe [[#Der Bearbeitungsstreit|
Der Bearbeitungsstreit]]): nicht ob man den Generalbass aussetzen
darf, sondern ''wie'' – und ob dabei die Klangsprache des
19. Jahrhunderts legitim ist.

== Der Bearbeitungsstreit ==

Franz' Ergänzungen des barocken Generalbasssatzes – also seine Ausführung der in Barockpartituren nur skizzenhaft notierten Begleitung – stießen auf scharfen Widerspruch der aufkommenden philologisch-historischen Schule. Besonders Friedrich Chrysander, Herausgeber der Händel-Gesamtausgabe, und Philipp Spitta, der maßgebliche Bach-Forscher der Zeit, kritisierten Franz' Herangehensweise als zu romantisierend und zu wenig historisch korrekt.

Franz seinerseits ließ sich das nicht gefallen. In einem [[Brief vom 1. Februar 1871 | Brief]] an seinen Freund Julius Schäffer schrieb er über Chrysander:

: ''„Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne gepachtet zu haben."''

Der Streit wurde auch öffentlich geführt. Schäffer verfasste zwischen 1875 und 1880 eine Reihe von Streitschriften zur Verteidigung der Franz'schen Bearbeitungen, darunter ''Entgegnung auf Ph. Spitta's Artikel: Über das Accompagnement in den Kompositionen Seb. Bachs'' und ''Friedr. Chrysander in seinen Klavierauszügen zur deutschen Händel-Ausgabe''. Franz selbst meldete sich mit einem ''Offenen Brief an Eduard Hanslick'' und den ''Mitteilungen über J. S. Bachs Magnificat'' zu Wort.

Auf Seiten der Franz'schen Bearbeitungen standen namhafte Praktiker wie Liszt, Felix Mottl, Hans Richter und Arthur Nikisch. Die philologische Schule – Chrysander, Spitta – pochte auf Texttreue.

Dieser Streit ist im Kern derselbe, der bis heute nicht wirklich entschieden ist: Wie viel interpretatorische Freiheit darf – oder muss – eine lebendige Aufführung alter Musik haben? Franz stand auf der Seite der musikalischen Praxis; die Gegenseite bereitete den Boden für das vor, was später als Historisch Informierte Aufführungspraxis bekannt werden sollte.

== Warum ist Robert Franz vergessen? ==

Das ist eine berechtigte Frage – und die Antwort ist vielschichtig:

* '''Das Gattungsproblem:''' Franz schrieb fast ausschließlich Lieder. Im 20. Jahrhundert rückte das Kunstlied zunehmend an den Rand des Konzertlebens. Komponisten, die auch Symphonien, Kammermusik oder größere Vokalwerke hinterlassen haben – Brahms, Schumann, Schubert –, blieben im Repertoire präsent. Franz nicht.

* '''Kein zyklisches Hauptwerk:''' Anders als Schubert mit der ''Winterreise'' oder der ''Schönen Müllerin'' hinterließ Franz keinen Liederzyklus, der als geschlossenes Abendprogramm funktioniert und vermarktbar ist.

* '''Kein überregionales Netzwerk:''' Franz lebte und arbeitete sein Leben lang in Halle. Er hatte keine Schüler, die seine Tradition weitergetragen hätten, und keine Präsenz in den großen Musikzentren Wien, Leipzig oder Berlin.

* '''Die Taubheit:''' 25 Jahre Isolation am Ende seines Lebens bedeuteten: kein Spätwerk, keine Weiterentwicklung, keine späten Meisterwerke wie bei Beethoven oder Schubert.

Schumann hatte Franz übrigens bereits früh ermahnt, sich nicht auf das Lied zu beschränken. Franz blieb trotzdem bei seiner Wahl – konsequent und ohne Kompromisse. Das verdient Respekt, auch wenn es seinen Nachruhm gekostet hat.

== Zeitgenössische Wertschätzung ==

Dass Franz zu Lebzeiten keineswegs unbekannt war, zeigt eine Episode aus dem Jahr 1873: Als seine finanzielle Lage nach dem Verlust seiner Ämter und Bezüge prekär wurde, organisierten Franz Liszt und andere namhafte Musikerpersönlichkeiten einen Ehrenfonds, der Franz den Lebensunterhalt sicherte. Liszt hatte zudem bereits 1872 eine Monographie über Franz verfasst.

== Weblinks und Quellen ==

* [https://www.deutsche-biographie.de/sfz16975.html Deutsche Biographie – Robert Franz] (Allgemeine Deutsche Biographie, Band 48, 1904)
* [https://de.wikipedia.org/wiki/Robert_Franz Wikipedia – Robert Franz]
* [https://www.musikland-sachsenanhalt.de/beitraege/franz-robert-1815-1892/ Musikland Sachsen-Anhalt – Robert Franz]
* [https://halle.de/kultur-tourismus/stadtgeschichte/bekannte-persoenlichkeiten/beruehmte-hallenser/details/franz-robert Berühmte Hallenser – Stadt Halle]
* [https://st.museum-digital.de/object/1102 Brief von Robert Franz an Julius Schäffer, 1. Februar 1871] – Stiftung Händel-Haus Halle (museum-digital Sachsen-Anhalt)
* [https://www.klassik-heute.com/4daction/www_komponist?id=43036&bio= Klassik Heute – Biographie Robert Franz]

----
''Seite erstellt im Kontext eines Konzertprogramms mit Liedern von Robert Franz, Mai 2026.''

Robert Franz (1815-1892), deutscher Komponist

2026-05-27T13:04:46Z

Admin:

{{DISPLAYTITLE:Robert Franz}}
[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]
Robert Franz (eigentlich Robert Franz Julius Knauth; * 28. Juni 1815 in Halle an der Saale; † 24. Oktober 1892 ebenda) war ein deutscher Komponist, Organist und Dirigent. Zu Lebzeiten von Zeitgenossen wie Robert Schumann, Franz Liszt und Felix Mendelssohn geschätzt, gehört er heute zu den weitgehend vergessenen Komponisten der deutschen Romantik.

[[Datei:Robert Franz.jpg|thumb|right|250px|Robert Franz (1815–1892)]]

== Leben ==

=== Herkunft und Ausbildung ===

Robert Franz stammte aus einer alteingesessenen Hallorer-Familie. (Siehe auch: [[Halloren]]).
Er wuchs in Halle auf, wo er ab 1828 die Latina der Franckeschen Stiftungen besuchte. Früh fiel er durch musikalische Begabung auf; der dortige Kantor Carl Gottlob Abela ließ ihn die Proben des Schulchors am Klavier begleiten. Von 1835 bis 1837 studierte er Komposition bei Friedrich Schneider in Dessau und kehrte danach nach Halle zurück – in eine Stadt, die er zeit seines Lebens kaum verlassen sollte.

=== Berufliche Laufbahn in Halle ===

Nach schwierigen wirtschaftlichen Anfangsjahren übernahm Franz 1841 das Organistenamt an der Ulrichskirche. Im folgenden Jahr wurde er Dirigent der Singakademie Halle, die später seinen Namen annahm. 1848 heiratete er Marie Hinrichs, Tochter eines Professors und selbst Komponistin; das Paar hatte drei Kinder. 1859 wurde Franz schließlich zum Universitätsmusikdirektor ernannt – der Höhepunkt seiner öffentlichen Laufbahn.

=== Krankheit und Rückzug ===

Seit 1843 litt Franz an einem Nerven- und Ohrenleiden, das sich über Jahrzehnte progressiv verschlimmerte und schließlich zur vollständigen Taubheit führte. 1867 wurde er beurlaubt,
1868 musste er alle Ämter endgültig aufgeben. Die daraus folgende finanzielle Not war erheblich: Ein 1867 zuerkannter Ehrensold wurde ihm 1877 auf Betreiben von Widersachern wieder entzogen. Seinen Lebensunterhalt sicherte schließlich ein 1873 von Freunden und Kollegen – allen voran Franz Liszt – gestifteter Ehrenfonds in Höhe von 30.000 Talern.

Die letzten rund 25 Jahre seines Lebens verbrachte Franz in nahezu vollständiger Taubheit und sozialem Rückzug. Er starb am 24. Oktober 1892 in Halle.

1885 wurde ihm zu seinem 70. Geburtstag – anlässlich der Feier des 200. Geburtstags Georg Friedrich Händels – das Ehrenbürgerrecht der Stadt Halle verliehen.

=== Familie ===

1848 heiratete Robert Franz in Halle Marie Hinrichs (1828–1891),
Tochter des Hallenser Philosophieprofessors Hermann Friedrich
Wilhelm Hinrichs. Marie Franz war selbst Komponistin und hatte bereits 1846 – also
zwei Jahre vor der Heirat – bei Breitkopf & Härtel in Leipzig einen
Band mit neun Gesängen für Singstimme und Klavier veröffentlicht.

Dem Paar wurden drei Kinder geboren. Bekannt sind: ein Sohn, der
1900 als praktischer Arzt in Heidelberg starb, sowie eine Tochter,
die den Superintendenten Bethge in Giebichenstein heiratete.

Marie Franz starb 1891 – ein Jahr vor ihrem Mann. Robert Franz,
taub und weitgehend isoliert, überlebte sie nur um ein Jahr.
Beide sind auf dem Stadtgottesacker in Halle begraben.

[[Datei:Robert-franz-im-alter.png |thumb|right|250px|Robert Franz, späte Aufnahme]]

== Das Werk ==

=== Die Lieder ===

Robert Franz schrieb über 350 Kunstlieder für Singstimme und Klavier – und fast ausschließlich das. Keine Symphonien, keine Opern, kein Streichquartett. Diese bewusste Konzentration auf eine einzige Gattung war seine Stärke und zugleich der Grund für sein späteres Vergessen.

Etwa ein Viertel seiner Lieder vertont Texte von Heinrich Heine. Daneben war Karl Wilhelm Osterwald ein bevorzugter Dichter. Franz' Vertonungsweise gilt als außerordentlich textgetreu und harmonisch differenziert – ohne Effekthascherei, in großer Zurückhaltung und mit feinem Klangsinn. Robert Schumann, dem Franz 1843 sein erstes gedrucktes Heft (op. 1, ''Zwölf Gesänge'') zuschickte, antwortete, die Lieder hätten ihm gefallen „wie seit langer Zeit keine mehr". Auch Mendelssohn, Liszt und Wagner äußerten sich anerkennend.

Zu den heute noch gelegentlich aufgeführten Liedern gehören:
* ''Aus meinen großen Schmerzen'', op. 5 Nr. 1 (Text: Heinrich Heine)
* ''Auf dem Meere'', op. 5 Nr. 3 (Text: Heinrich Heine)
* ''Sterne mit den goldnen Füßchen'' (Text: Heinrich Heine)
* ''Schilflieder'', op. 2 (Text: Nikolaus Lenau)

Die Opuszahlen von ''Sterne mit den goldnen Füßchen''
konnten nicht zweifelsfrei belegt werden.

=== Bearbeitungen von Bach und Händel ===

Neben seinen Liedern hat sich Franz einen – weniger bekannten, aber musikhistorisch bedeutsamen – Namen als Bearbeiter älterer Musik erworben. Als Leiter der Singakademie brachte er Werke von Johann Sebastian Bach und Georg Friedrich Händel zur Aufführung und fertigte dafür eigene Bearbeitungen an, die den Werken eine für das 19. Jahrhundert spielbare Gestalt gaben.

Zu seinen wichtigsten Bearbeitungen zählen:
* J. S. Bach: Matthäuspassion, Magnificat, Weihnachtsoratorium, Trauerode, zahlreiche Kantaten
* G. F. Händel: Messias, Jubilate, L'Allegro il Pensieroso ed il Moderato, Arien und Duette

Diese Bearbeitungen waren unter Musikern höchst umstritten – und führten zu einem der interessantesten musikwissenschaftlichen Streits der zweiten Hälfte des 19. Jahrhunderts (siehe unten).

== Der Bearbeitungsstreit ==

Franz' Ergänzungen des barocken Generalbasssatzes – also seine Ausführung der in Barockpartituren nur skizzenhaft notierten Begleitung – stießen auf scharfen Widerspruch der aufkommenden philologisch-historischen Schule. Besonders Friedrich Chrysander, Herausgeber der Händel-Gesamtausgabe, und Philipp Spitta, der maßgebliche Bach-Forscher der Zeit, kritisierten Franz' Herangehensweise als zu romantisierend und zu wenig historisch korrekt.

Franz seinerseits ließ sich das nicht gefallen. In einem [[Brief vom 1. Februar 1871 | Brief]] an seinen Freund Julius Schäffer schrieb er über Chrysander:

: ''„Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne gepachtet zu haben."''

Der Streit wurde auch öffentlich geführt. Schäffer verfasste zwischen 1875 und 1880 eine Reihe von Streitschriften zur Verteidigung der Franz'schen Bearbeitungen, darunter ''Entgegnung auf Ph. Spitta's Artikel: Über das Accompagnement in den Kompositionen Seb. Bachs'' und ''Friedr. Chrysander in seinen Klavierauszügen zur deutschen Händel-Ausgabe''. Franz selbst meldete sich mit einem ''Offenen Brief an Eduard Hanslick'' und den ''Mitteilungen über J. S. Bachs Magnificat'' zu Wort.

Auf Seiten der Franz'schen Bearbeitungen standen namhafte Praktiker wie Liszt, Felix Mottl, Hans Richter und Arthur Nikisch. Die philologische Schule – Chrysander, Spitta – pochte auf Texttreue.

Dieser Streit ist im Kern derselbe, der bis heute nicht wirklich entschieden ist: Wie viel interpretatorische Freiheit darf – oder muss – eine lebendige Aufführung alter Musik haben? Franz stand auf der Seite der musikalischen Praxis; die Gegenseite bereitete den Boden für das vor, was später als Historisch Informierte Aufführungspraxis bekannt werden sollte.

== Warum ist Robert Franz vergessen? ==

Das ist eine berechtigte Frage – und die Antwort ist vielschichtig:

* '''Das Gattungsproblem:''' Franz schrieb fast ausschließlich Lieder. Im 20. Jahrhundert rückte das Kunstlied zunehmend an den Rand des Konzertlebens. Komponisten, die auch Symphonien, Kammermusik oder größere Vokalwerke hinterlassen haben – Brahms, Schumann, Schubert –, blieben im Repertoire präsent. Franz nicht.

* '''Kein zyklisches Hauptwerk:''' Anders als Schubert mit der ''Winterreise'' oder der ''Schönen Müllerin'' hinterließ Franz keinen Liederzyklus, der als geschlossenes Abendprogramm funktioniert und vermarktbar ist.

* '''Kein überregionales Netzwerk:''' Franz lebte und arbeitete sein Leben lang in Halle. Er hatte keine Schüler, die seine Tradition weitergetragen hätten, und keine Präsenz in den großen Musikzentren Wien, Leipzig oder Berlin.

* '''Die Taubheit:''' 25 Jahre Isolation am Ende seines Lebens bedeuteten: kein Spätwerk, keine Weiterentwicklung, keine späten Meisterwerke wie bei Beethoven oder Schubert.

Schumann hatte Franz übrigens bereits früh ermahnt, sich nicht auf das Lied zu beschränken. Franz blieb trotzdem bei seiner Wahl – konsequent und ohne Kompromisse. Das verdient Respekt, auch wenn es seinen Nachruhm gekostet hat.

== Zeitgenössische Wertschätzung ==

Dass Franz zu Lebzeiten keineswegs unbekannt war, zeigt eine Episode aus dem Jahr 1873: Als seine finanzielle Lage nach dem Verlust seiner Ämter und Bezüge prekär wurde, organisierten Franz Liszt und andere namhafte Musikerpersönlichkeiten einen Ehrenfonds, der Franz den Lebensunterhalt sicherte. Liszt hatte zudem bereits 1872 eine Monographie über Franz verfasst.

== Weblinks und Quellen ==

* [https://www.deutsche-biographie.de/sfz16975.html Deutsche Biographie – Robert Franz] (Allgemeine Deutsche Biographie, Band 48, 1904)
* [https://de.wikipedia.org/wiki/Robert_Franz Wikipedia – Robert Franz]
* [https://www.musikland-sachsenanhalt.de/beitraege/franz-robert-1815-1892/ Musikland Sachsen-Anhalt – Robert Franz]
* [https://halle.de/kultur-tourismus/stadtgeschichte/bekannte-persoenlichkeiten/beruehmte-hallenser/details/franz-robert Berühmte Hallenser – Stadt Halle]
* [https://st.museum-digital.de/object/1102 Brief von Robert Franz an Julius Schäffer, 1. Februar 1871] – Stiftung Händel-Haus Halle (museum-digital Sachsen-Anhalt)
* [https://www.klassik-heute.com/4daction/www_komponist?id=43036&bio= Klassik Heute – Biographie Robert Franz]

----
''Seite erstellt im Kontext eines Konzertprogramms mit Liedern von Robert Franz, Mai 2026.''

Robert Franz (1815-1892), deutscher Komponist

2026-05-27T13:04:28Z

Admin:

{{DISPLAYTITLE:Robert Franz}}
[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]
Robert Franz (eigentlich Robert Franz Julius Knauth;
* 28. Juni 1815 in Halle an der Saale; † 24. Oktober 1892 ebenda) war ein deutscher Komponist, Organist und Dirigent. Zu Lebzeiten von Zeitgenossen wie Robert Schumann, Franz Liszt und Felix Mendelssohn geschätzt, gehört er heute zu den weitgehend vergessenen Komponisten der deutschen Romantik.

[[Datei:Robert Franz.jpg|thumb|right|250px|Robert Franz (1815–1892)]]

== Leben ==

=== Herkunft und Ausbildung ===

Robert Franz stammte aus einer alteingesessenen Hallorer-Familie. (Siehe auch: [[Halloren]]).
Er wuchs in Halle auf, wo er ab 1828 die Latina der Franckeschen Stiftungen besuchte. Früh fiel er durch musikalische Begabung auf; der dortige Kantor Carl Gottlob Abela ließ ihn die Proben des Schulchors am Klavier begleiten. Von 1835 bis 1837 studierte er Komposition bei Friedrich Schneider in Dessau und kehrte danach nach Halle zurück – in eine Stadt, die er zeit seines Lebens kaum verlassen sollte.

=== Berufliche Laufbahn in Halle ===

Nach schwierigen wirtschaftlichen Anfangsjahren übernahm Franz 1841 das Organistenamt an der Ulrichskirche. Im folgenden Jahr wurde er Dirigent der Singakademie Halle, die später seinen Namen annahm. 1848 heiratete er Marie Hinrichs, Tochter eines Professors und selbst Komponistin; das Paar hatte drei Kinder. 1859 wurde Franz schließlich zum Universitätsmusikdirektor ernannt – der Höhepunkt seiner öffentlichen Laufbahn.

=== Krankheit und Rückzug ===

Seit 1843 litt Franz an einem Nerven- und Ohrenleiden, das sich über Jahrzehnte progressiv verschlimmerte und schließlich zur vollständigen Taubheit führte. 1867 wurde er beurlaubt,
1868 musste er alle Ämter endgültig aufgeben. Die daraus folgende finanzielle Not war erheblich: Ein 1867 zuerkannter Ehrensold wurde ihm 1877 auf Betreiben von Widersachern wieder entzogen. Seinen Lebensunterhalt sicherte schließlich ein 1873 von Freunden und Kollegen – allen voran Franz Liszt – gestifteter Ehrenfonds in Höhe von 30.000 Talern.

Die letzten rund 25 Jahre seines Lebens verbrachte Franz in nahezu vollständiger Taubheit und sozialem Rückzug. Er starb am 24. Oktober 1892 in Halle.

1885 wurde ihm zu seinem 70. Geburtstag – anlässlich der Feier des 200. Geburtstags Georg Friedrich Händels – das Ehrenbürgerrecht der Stadt Halle verliehen.

=== Familie ===

1848 heiratete Robert Franz in Halle Marie Hinrichs (1828–1891),
Tochter des Hallenser Philosophieprofessors Hermann Friedrich
Wilhelm Hinrichs. Marie Franz war selbst Komponistin und hatte bereits 1846 – also
zwei Jahre vor der Heirat – bei Breitkopf & Härtel in Leipzig einen
Band mit neun Gesängen für Singstimme und Klavier veröffentlicht.

Dem Paar wurden drei Kinder geboren. Bekannt sind: ein Sohn, der
1900 als praktischer Arzt in Heidelberg starb, sowie eine Tochter,
die den Superintendenten Bethge in Giebichenstein heiratete.

Marie Franz starb 1891 – ein Jahr vor ihrem Mann. Robert Franz,
taub und weitgehend isoliert, überlebte sie nur um ein Jahr.
Beide sind auf dem Stadtgottesacker in Halle begraben.

[[Datei:Robert-franz-im-alter.png |thumb|right|250px|Robert Franz, späte Aufnahme]]

== Das Werk ==

=== Die Lieder ===

Robert Franz schrieb über 350 Kunstlieder für Singstimme und Klavier – und fast ausschließlich das. Keine Symphonien, keine Opern, kein Streichquartett. Diese bewusste Konzentration auf eine einzige Gattung war seine Stärke und zugleich der Grund für sein späteres Vergessen.

Etwa ein Viertel seiner Lieder vertont Texte von Heinrich Heine. Daneben war Karl Wilhelm Osterwald ein bevorzugter Dichter. Franz' Vertonungsweise gilt als außerordentlich textgetreu und harmonisch differenziert – ohne Effekthascherei, in großer Zurückhaltung und mit feinem Klangsinn. Robert Schumann, dem Franz 1843 sein erstes gedrucktes Heft (op. 1, ''Zwölf Gesänge'') zuschickte, antwortete, die Lieder hätten ihm gefallen „wie seit langer Zeit keine mehr". Auch Mendelssohn, Liszt und Wagner äußerten sich anerkennend.

Zu den heute noch gelegentlich aufgeführten Liedern gehören:
* ''Aus meinen großen Schmerzen'', op. 5 Nr. 1 (Text: Heinrich Heine)
* ''Auf dem Meere'', op. 5 Nr. 3 (Text: Heinrich Heine)
* ''Sterne mit den goldnen Füßchen'' (Text: Heinrich Heine)
* ''Schilflieder'', op. 2 (Text: Nikolaus Lenau)

Die Opuszahlen von ''Sterne mit den goldnen Füßchen''
konnten nicht zweifelsfrei belegt werden.

=== Bearbeitungen von Bach und Händel ===

Neben seinen Liedern hat sich Franz einen – weniger bekannten, aber musikhistorisch bedeutsamen – Namen als Bearbeiter älterer Musik erworben. Als Leiter der Singakademie brachte er Werke von Johann Sebastian Bach und Georg Friedrich Händel zur Aufführung und fertigte dafür eigene Bearbeitungen an, die den Werken eine für das 19. Jahrhundert spielbare Gestalt gaben.

Zu seinen wichtigsten Bearbeitungen zählen:
* J. S. Bach: Matthäuspassion, Magnificat, Weihnachtsoratorium, Trauerode, zahlreiche Kantaten
* G. F. Händel: Messias, Jubilate, L'Allegro il Pensieroso ed il Moderato, Arien und Duette

Diese Bearbeitungen waren unter Musikern höchst umstritten – und führten zu einem der interessantesten musikwissenschaftlichen Streits der zweiten Hälfte des 19. Jahrhunderts (siehe unten).

== Der Bearbeitungsstreit ==

Franz' Ergänzungen des barocken Generalbasssatzes – also seine Ausführung der in Barockpartituren nur skizzenhaft notierten Begleitung – stießen auf scharfen Widerspruch der aufkommenden philologisch-historischen Schule. Besonders Friedrich Chrysander, Herausgeber der Händel-Gesamtausgabe, und Philipp Spitta, der maßgebliche Bach-Forscher der Zeit, kritisierten Franz' Herangehensweise als zu romantisierend und zu wenig historisch korrekt.

Franz seinerseits ließ sich das nicht gefallen. In einem [[Brief vom 1. Februar 1871 | Brief]] an seinen Freund Julius Schäffer schrieb er über Chrysander:

: ''„Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne gepachtet zu haben."''

Der Streit wurde auch öffentlich geführt. Schäffer verfasste zwischen 1875 und 1880 eine Reihe von Streitschriften zur Verteidigung der Franz'schen Bearbeitungen, darunter ''Entgegnung auf Ph. Spitta's Artikel: Über das Accompagnement in den Kompositionen Seb. Bachs'' und ''Friedr. Chrysander in seinen Klavierauszügen zur deutschen Händel-Ausgabe''. Franz selbst meldete sich mit einem ''Offenen Brief an Eduard Hanslick'' und den ''Mitteilungen über J. S. Bachs Magnificat'' zu Wort.

Auf Seiten der Franz'schen Bearbeitungen standen namhafte Praktiker wie Liszt, Felix Mottl, Hans Richter und Arthur Nikisch. Die philologische Schule – Chrysander, Spitta – pochte auf Texttreue.

Dieser Streit ist im Kern derselbe, der bis heute nicht wirklich entschieden ist: Wie viel interpretatorische Freiheit darf – oder muss – eine lebendige Aufführung alter Musik haben? Franz stand auf der Seite der musikalischen Praxis; die Gegenseite bereitete den Boden für das vor, was später als Historisch Informierte Aufführungspraxis bekannt werden sollte.

== Warum ist Robert Franz vergessen? ==

Das ist eine berechtigte Frage – und die Antwort ist vielschichtig:

* '''Das Gattungsproblem:''' Franz schrieb fast ausschließlich Lieder. Im 20. Jahrhundert rückte das Kunstlied zunehmend an den Rand des Konzertlebens. Komponisten, die auch Symphonien, Kammermusik oder größere Vokalwerke hinterlassen haben – Brahms, Schumann, Schubert –, blieben im Repertoire präsent. Franz nicht.

* '''Kein zyklisches Hauptwerk:''' Anders als Schubert mit der ''Winterreise'' oder der ''Schönen Müllerin'' hinterließ Franz keinen Liederzyklus, der als geschlossenes Abendprogramm funktioniert und vermarktbar ist.

* '''Kein überregionales Netzwerk:''' Franz lebte und arbeitete sein Leben lang in Halle. Er hatte keine Schüler, die seine Tradition weitergetragen hätten, und keine Präsenz in den großen Musikzentren Wien, Leipzig oder Berlin.

* '''Die Taubheit:''' 25 Jahre Isolation am Ende seines Lebens bedeuteten: kein Spätwerk, keine Weiterentwicklung, keine späten Meisterwerke wie bei Beethoven oder Schubert.

Schumann hatte Franz übrigens bereits früh ermahnt, sich nicht auf das Lied zu beschränken. Franz blieb trotzdem bei seiner Wahl – konsequent und ohne Kompromisse. Das verdient Respekt, auch wenn es seinen Nachruhm gekostet hat.

== Zeitgenössische Wertschätzung ==

Dass Franz zu Lebzeiten keineswegs unbekannt war, zeigt eine Episode aus dem Jahr 1873: Als seine finanzielle Lage nach dem Verlust seiner Ämter und Bezüge prekär wurde, organisierten Franz Liszt und andere namhafte Musikerpersönlichkeiten einen Ehrenfonds, der Franz den Lebensunterhalt sicherte. Liszt hatte zudem bereits 1872 eine Monographie über Franz verfasst.

== Weblinks und Quellen ==

* [https://www.deutsche-biographie.de/sfz16975.html Deutsche Biographie – Robert Franz] (Allgemeine Deutsche Biographie, Band 48, 1904)
* [https://de.wikipedia.org/wiki/Robert_Franz Wikipedia – Robert Franz]
* [https://www.musikland-sachsenanhalt.de/beitraege/franz-robert-1815-1892/ Musikland Sachsen-Anhalt – Robert Franz]
* [https://halle.de/kultur-tourismus/stadtgeschichte/bekannte-persoenlichkeiten/beruehmte-hallenser/details/franz-robert Berühmte Hallenser – Stadt Halle]
* [https://st.museum-digital.de/object/1102 Brief von Robert Franz an Julius Schäffer, 1. Februar 1871] – Stiftung Händel-Haus Halle (museum-digital Sachsen-Anhalt)
* [https://www.klassik-heute.com/4daction/www_komponist?id=43036&bio= Klassik Heute – Biographie Robert Franz]

----
''Seite erstellt im Kontext eines Konzertprogramms mit Liedern von Robert Franz, Mai 2026.''

Robert Franz (1815-1892), deutscher Komponist

2026-05-27T12:43:21Z

Admin:

{{DISPLAYTITLE:Robert Franz}}
[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]

'''Robert Franz''' (eigentlich Robert Franz Julius Knauth; * 28. Juni 1815 in Halle an der Saale; † 24. Oktober 1892 ebenda) war ein deutscher Komponist, Organist und Dirigent. Er gilt als einer der bedeutendsten Liedkomponisten der deutschen Romantik – und gehört gleichzeitig zu den am stärksten vergessenen.

[[Datei:Robert Franz.jpg|thumb|right|250px|Robert Franz (1815–1892)]]

== Leben ==

=== Herkunft und Ausbildung ===

Robert Franz stammte aus einer alteingesessenen Hallorer-Familie. (Siehe auch: [[Halloren]]).
Er wuchs in Halle auf, wo er ab 1828 die Latina der Franckeschen Stiftungen besuchte. Früh fiel er durch musikalische Begabung auf; der dortige Kantor Carl Gottlob Abela ließ ihn die Proben des Schulchors am Klavier begleiten. Von 1835 bis 1837 studierte er Komposition bei Friedrich Schneider in Dessau und kehrte danach nach Halle zurück – in eine Stadt, die er zeit seines Lebens kaum verlassen sollte.

=== Berufliche Laufbahn in Halle ===

Nach schwierigen wirtschaftlichen Anfangsjahren übernahm Franz 1841 das Organistenamt an der Ulrichskirche. Im folgenden Jahr wurde er Dirigent der Singakademie Halle, die später seinen Namen annahm. 1848 heiratete er Marie Hinrichs, Tochter eines Professors und selbst Komponistin; das Paar hatte drei Kinder. 1859 wurde Franz schließlich zum Universitätsmusikdirektor ernannt – der Höhepunkt seiner öffentlichen Laufbahn.

=== Krankheit und Rückzug ===

Seit 1843 litt Franz an einem Nerven- und Ohrenleiden, das sich über Jahrzehnte progressiv verschlimmerte und schließlich zur vollständigen Taubheit führte. 1867 wurde er beurlaubt,
1868 musste er alle Ämter endgültig aufgeben. Die daraus folgende finanzielle Not war erheblich: Ein 1867 zuerkannter Ehrensold wurde ihm 1877 auf Betreiben von Widersachern wieder entzogen. Seinen Lebensunterhalt sicherte schließlich ein 1873 von Freunden und Kollegen – allen voran Franz Liszt – gestifteter Ehrenfonds in Höhe von 30.000 Talern.

Die letzten rund 25 Jahre seines Lebens verbrachte Franz in nahezu vollständiger Taubheit und sozialem Rückzug. Er starb am 24. Oktober 1892 in Halle.

1885 wurde ihm zu seinem 70. Geburtstag – anlässlich der Feier des 200. Geburtstags Georg Friedrich Händels – das Ehrenbürgerrecht der Stadt Halle verliehen.

=== Familie ===

1848 heiratete Robert Franz in Halle Marie Hinrichs (1828–1891),
Tochter des Hallenser Philosophieprofessors Hermann Friedrich
Wilhelm Hinrichs. Marie Franz war selbst Komponistin und hatte bereits 1846 – also
zwei Jahre vor der Heirat – bei Breitkopf & Härtel in Leipzig einen
Band mit neun Gesängen für Singstimme und Klavier veröffentlicht.

Dem Paar wurden drei Kinder geboren. Bekannt sind: ein Sohn, der
1900 als praktischer Arzt in Heidelberg starb, sowie eine Tochter,
die den Superintendenten Bethge in Giebichenstein heiratete.

Marie Franz starb 1891 – ein Jahr vor ihrem Mann. Robert Franz,
taub und weitgehend isoliert, überlebte sie nur um ein Jahr.
Beide sind auf dem Stadtgottesacker in Halle begraben.

[[Datei:Robert-franz-im-alter.png |thumb|right|250px|Robert Franz, späte Aufnahme]]

== Das Werk ==

=== Die Lieder ===

Robert Franz schrieb über 350 Kunstlieder für Singstimme und Klavier – und fast ausschließlich das. Keine Symphonien, keine Opern, kein Streichquartett. Diese bewusste Konzentration auf eine einzige Gattung war seine Stärke und zugleich der Grund für sein späteres Vergessen.

Etwa ein Viertel seiner Lieder vertont Texte von Heinrich Heine. Daneben war Karl Wilhelm Osterwald ein bevorzugter Dichter. Franz' Vertonungsweise gilt als außerordentlich textgetreu und harmonisch differenziert – ohne Effekthascherei, in großer Zurückhaltung und mit feinem Klangsinn. Robert Schumann, dem Franz 1843 sein erstes gedrucktes Heft (op. 1, ''Zwölf Gesänge'') zuschickte, antwortete, die Lieder hätten ihm gefallen „wie seit langer Zeit keine mehr". Auch Mendelssohn, Liszt und Wagner äußerten sich anerkennend.

Zu den heute noch gelegentlich aufgeführten Liedern gehören:
* ''Aus meinen großen Schmerzen'', op. 5 Nr. 1 (Text: Heinrich Heine)
* ''Auf dem Meere'', op. 5 Nr. 3 (Text: Heinrich Heine)
* ''Sterne mit den goldnen Füßchen'' (Text: Heinrich Heine)
* ''Schilflieder'', op. 2 (Text: Nikolaus Lenau)

Die Opuszahlen von ''Sterne mit den goldnen Füßchen''
konnten nicht zweifelsfrei belegt werden.

=== Bearbeitungen von Bach und Händel ===

Neben seinen Liedern hat sich Franz einen – weniger bekannten, aber musikhistorisch bedeutsamen – Namen als Bearbeiter älterer Musik erworben. Als Leiter der Singakademie brachte er Werke von Johann Sebastian Bach und Georg Friedrich Händel zur Aufführung und fertigte dafür eigene Bearbeitungen an, die den Werken eine für das 19. Jahrhundert spielbare Gestalt gaben.

Zu seinen wichtigsten Bearbeitungen zählen:
* J. S. Bach: Matthäuspassion, Magnificat, Weihnachtsoratorium, Trauerode, zahlreiche Kantaten
* G. F. Händel: Messias, Jubilate, L'Allegro il Pensieroso ed il Moderato, Arien und Duette

Diese Bearbeitungen waren unter Musikern höchst umstritten – und führten zu einem der interessantesten musikwissenschaftlichen Streits der zweiten Hälfte des 19. Jahrhunderts (siehe unten).

== Der Bearbeitungsstreit ==

Franz' Ergänzungen des barocken Generalbasssatzes – also seine Ausführung der in Barockpartituren nur skizzenhaft notierten Begleitung – stießen auf scharfen Widerspruch der aufkommenden philologisch-historischen Schule. Besonders Friedrich Chrysander, Herausgeber der Händel-Gesamtausgabe, und Philipp Spitta, der maßgebliche Bach-Forscher der Zeit, kritisierten Franz' Herangehensweise als zu romantisierend und zu wenig historisch korrekt.

Franz seinerseits ließ sich das nicht gefallen. In einem [[Brief vom 1. Februar 1871 | Brief]] an seinen Freund Julius Schäffer schrieb er über Chrysander:

: ''„Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne gepachtet zu haben."''

Der Streit wurde auch öffentlich geführt. Schäffer verfasste zwischen 1875 und 1880 eine Reihe von Streitschriften zur Verteidigung der Franz'schen Bearbeitungen, darunter ''Entgegnung auf Ph. Spitta's Artikel: Über das Accompagnement in den Kompositionen Seb. Bachs'' und ''Friedr. Chrysander in seinen Klavierauszügen zur deutschen Händel-Ausgabe''. Franz selbst meldete sich mit einem ''Offenen Brief an Eduard Hanslick'' und den ''Mitteilungen über J. S. Bachs Magnificat'' zu Wort.

Auf Seiten der Franz'schen Bearbeitungen standen namhafte Praktiker wie Liszt, Felix Mottl, Hans Richter und Arthur Nikisch. Die philologische Schule – Chrysander, Spitta – pochte auf Texttreue.

Dieser Streit ist im Kern derselbe, der bis heute nicht wirklich entschieden ist: Wie viel interpretatorische Freiheit darf – oder muss – eine lebendige Aufführung alter Musik haben? Franz stand auf der Seite der musikalischen Praxis; die Gegenseite bereitete den Boden für das vor, was später als Historisch Informierte Aufführungspraxis bekannt werden sollte.

== Warum ist Robert Franz vergessen? ==

Das ist eine berechtigte Frage – und die Antwort ist vielschichtig:

* '''Das Gattungsproblem:''' Franz schrieb fast ausschließlich Lieder. Im 20. Jahrhundert rückte das Kunstlied zunehmend an den Rand des Konzertlebens. Komponisten, die auch Symphonien, Kammermusik oder größere Vokalwerke hinterlassen haben – Brahms, Schumann, Schubert –, blieben im Repertoire präsent. Franz nicht.

* '''Kein zyklisches Hauptwerk:''' Anders als Schubert mit der ''Winterreise'' oder der ''Schönen Müllerin'' hinterließ Franz keinen Liederzyklus, der als geschlossenes Abendprogramm funktioniert und vermarktbar ist.

* '''Kein überregionales Netzwerk:''' Franz lebte und arbeitete sein Leben lang in Halle. Er hatte keine Schüler, die seine Tradition weitergetragen hätten, und keine Präsenz in den großen Musikzentren Wien, Leipzig oder Berlin.

* '''Die Taubheit:''' 25 Jahre Isolation am Ende seines Lebens bedeuteten: kein Spätwerk, keine Weiterentwicklung, keine späten Meisterwerke wie bei Beethoven oder Schubert.

Schumann hatte Franz übrigens bereits früh ermahnt, sich nicht auf das Lied zu beschränken. Franz blieb trotzdem bei seiner Wahl – konsequent und ohne Kompromisse. Das verdient Respekt, auch wenn es seinen Nachruhm gekostet hat.

== Zeitgenössische Wertschätzung ==

Dass Franz zu Lebzeiten keineswegs unbekannt war, zeigt eine Episode aus dem Jahr 1873: Als seine finanzielle Lage nach dem Verlust seiner Ämter und Bezüge prekär wurde, organisierten Franz Liszt und andere namhafte Musikerpersönlichkeiten einen Ehrenfonds, der Franz den Lebensunterhalt sicherte. Liszt hatte zudem bereits 1872 eine Monographie über Franz verfasst.

== Weblinks und Quellen ==

* [https://www.deutsche-biographie.de/sfz16975.html Deutsche Biographie – Robert Franz] (Allgemeine Deutsche Biographie, Band 48, 1904)
* [https://de.wikipedia.org/wiki/Robert_Franz Wikipedia – Robert Franz]
* [https://www.musikland-sachsenanhalt.de/beitraege/franz-robert-1815-1892/ Musikland Sachsen-Anhalt – Robert Franz]
* [https://halle.de/kultur-tourismus/stadtgeschichte/bekannte-persoenlichkeiten/beruehmte-hallenser/details/franz-robert Berühmte Hallenser – Stadt Halle]
* [https://st.museum-digital.de/object/1102 Brief von Robert Franz an Julius Schäffer, 1. Februar 1871] – Stiftung Händel-Haus Halle (museum-digital Sachsen-Anhalt)
* [https://www.klassik-heute.com/4daction/www_komponist?id=43036&bio= Klassik Heute – Biographie Robert Franz]

----
''Seite erstellt im Kontext eines Konzertprogramms mit Liedern von Robert Franz, Mai 2026.''

Robert Franz (1815-1892), deutscher Komponist

2026-05-27T12:36:33Z

Admin: /* Krankheit und Rückzug */

{{DISPLAYTITLE:Robert Franz}}
[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]

'''Robert Franz''' (eigentlich Robert Franz Julius Knauth; * 28. Juni 1815 in Halle an der Saale; † 24. Oktober 1892 ebenda) war ein deutscher Komponist, Organist und Dirigent. Er gilt als einer der bedeutendsten Liedkomponisten der deutschen Romantik – und gehört gleichzeitig zu den am stärksten vergessenen.

[[Datei:Robert Franz.jpg|thumb|right|250px|Robert Franz (1815–1892)]]

== Leben ==

=== Herkunft und Ausbildung ===

Robert Franz stammte aus einer alteingesessenen Hallorer-Familie. (Siehe auch: [[Halloren]]).
Er wuchs in Halle auf, wo er ab 1828 die Latina der Franckeschen Stiftungen besuchte. Früh fiel er durch musikalische Begabung auf; der dortige Kantor Carl Gottlob Abela ließ ihn die Proben des Schulchors am Klavier begleiten. Von 1835 bis 1837 studierte er Komposition bei Friedrich Schneider in Dessau und kehrte danach nach Halle zurück – in eine Stadt, die er zeit seines Lebens kaum verlassen sollte.

=== Berufliche Laufbahn in Halle ===

Nach schwierigen wirtschaftlichen Anfangsjahren übernahm Franz 1841 das Organistenamt an der Ulrichskirche. Im folgenden Jahr wurde er Dirigent der Singakademie Halle, die später seinen Namen annahm. 1848 heiratete er Marie Hinrichs, Tochter eines Professors und selbst Komponistin; das Paar hatte drei Kinder. 1859 wurde Franz schließlich zum Universitätsmusikdirektor ernannt – der Höhepunkt seiner öffentlichen Laufbahn.

=== Krankheit und Rückzug ===

Seit 1843 litt Franz an einem Nerven- und Ohrenleiden, das sich über Jahrzehnte progressiv verschlimmerte und schließlich zur vollständigen Taubheit führte. 1867 wurde er beurlaubt,
1868 musste er alle Ämter endgültig aufgeben. Die daraus folgende finanzielle Not war erheblich: Ein 1867 zuerkannter Ehrensold wurde ihm 1877 auf Betreiben von Widersachern wieder entzogen. Seinen Lebensunterhalt sicherte schließlich ein 1873 von Freunden und Kollegen – allen voran Franz Liszt – gestifteter Ehrenfonds in Höhe von 30.000 Talern.

Die letzten rund 25 Jahre seines Lebens verbrachte Franz in nahezu vollständiger Taubheit und sozialem Rückzug. Er starb am 24. Oktober 1892 in Halle.

1885 wurde ihm zu seinem 70. Geburtstag – anlässlich der Feier des 200. Geburtstags Georg Friedrich Händels – das Ehrenbürgerrecht der Stadt Halle verliehen.

[[Datei:Robert-franz-im-alter.png |thumb|right|250px|Robert Franz, späte Aufnahme]]

== Das Werk ==

=== Die Lieder ===

Robert Franz schrieb über 350 Kunstlieder für Singstimme und Klavier – und fast ausschließlich das. Keine Symphonien, keine Opern, kein Streichquartett. Diese bewusste Konzentration auf eine einzige Gattung war seine Stärke und zugleich der Grund für sein späteres Vergessen.

Etwa ein Viertel seiner Lieder vertont Texte von Heinrich Heine. Daneben war Karl Wilhelm Osterwald ein bevorzugter Dichter. Franz' Vertonungsweise gilt als außerordentlich textgetreu und harmonisch differenziert – ohne Effekthascherei, in großer Zurückhaltung und mit feinem Klangsinn. Robert Schumann, dem Franz 1843 sein erstes gedrucktes Heft (op. 1, ''Zwölf Gesänge'') zuschickte, antwortete, die Lieder hätten ihm gefallen „wie seit langer Zeit keine mehr". Auch Mendelssohn, Liszt und Wagner äußerten sich anerkennend.

Zu den heute noch gelegentlich aufgeführten Liedern gehören:
* ''Aus meinen großen Schmerzen'', op. 5 Nr. 1 (Text: Heinrich Heine)
* ''Auf dem Meere'', op. 5 Nr. 3 (Text: Heinrich Heine)
* ''Sterne mit den goldnen Füßchen'' (Text: Heinrich Heine)
* ''Schilflieder'', op. 2 (Text: Nikolaus Lenau)

Die Opuszahlen von ''Sterne mit den goldnen Füßchen''
konnten nicht zweifelsfrei belegt werden.

=== Bearbeitungen von Bach und Händel ===

Neben seinen Liedern hat sich Franz einen – weniger bekannten, aber musikhistorisch bedeutsamen – Namen als Bearbeiter älterer Musik erworben. Als Leiter der Singakademie brachte er Werke von Johann Sebastian Bach und Georg Friedrich Händel zur Aufführung und fertigte dafür eigene Bearbeitungen an, die den Werken eine für das 19. Jahrhundert spielbare Gestalt gaben.

Zu seinen wichtigsten Bearbeitungen zählen:
* J. S. Bach: Matthäuspassion, Magnificat, Weihnachtsoratorium, Trauerode, zahlreiche Kantaten
* G. F. Händel: Messias, Jubilate, L'Allegro il Pensieroso ed il Moderato, Arien und Duette

Diese Bearbeitungen waren unter Musikern höchst umstritten – und führten zu einem der interessantesten musikwissenschaftlichen Streits der zweiten Hälfte des 19. Jahrhunderts (siehe unten).

== Der Bearbeitungsstreit ==

Franz' Ergänzungen des barocken Generalbasssatzes – also seine Ausführung der in Barockpartituren nur skizzenhaft notierten Begleitung – stießen auf scharfen Widerspruch der aufkommenden philologisch-historischen Schule. Besonders Friedrich Chrysander, Herausgeber der Händel-Gesamtausgabe, und Philipp Spitta, der maßgebliche Bach-Forscher der Zeit, kritisierten Franz' Herangehensweise als zu romantisierend und zu wenig historisch korrekt.

Franz seinerseits ließ sich das nicht gefallen. In einem [[Brief vom 1. Februar 1871 | Brief]] an seinen Freund Julius Schäffer schrieb er über Chrysander:

: ''„Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne gepachtet zu haben."''

Der Streit wurde auch öffentlich geführt. Schäffer verfasste zwischen 1875 und 1880 eine Reihe von Streitschriften zur Verteidigung der Franz'schen Bearbeitungen, darunter ''Entgegnung auf Ph. Spitta's Artikel: Über das Accompagnement in den Kompositionen Seb. Bachs'' und ''Friedr. Chrysander in seinen Klavierauszügen zur deutschen Händel-Ausgabe''. Franz selbst meldete sich mit einem ''Offenen Brief an Eduard Hanslick'' und den ''Mitteilungen über J. S. Bachs Magnificat'' zu Wort.

Auf Seiten der Franz'schen Bearbeitungen standen namhafte Praktiker wie Liszt, Felix Mottl, Hans Richter und Arthur Nikisch. Die philologische Schule – Chrysander, Spitta – pochte auf Texttreue.

Dieser Streit ist im Kern derselbe, der bis heute nicht wirklich entschieden ist: Wie viel interpretatorische Freiheit darf – oder muss – eine lebendige Aufführung alter Musik haben? Franz stand auf der Seite der musikalischen Praxis; die Gegenseite bereitete den Boden für das vor, was später als Historisch Informierte Aufführungspraxis bekannt werden sollte.

== Warum ist Robert Franz vergessen? ==

Das ist eine berechtigte Frage – und die Antwort ist vielschichtig:

* '''Das Gattungsproblem:''' Franz schrieb fast ausschließlich Lieder. Im 20. Jahrhundert rückte das Kunstlied zunehmend an den Rand des Konzertlebens. Komponisten, die auch Symphonien, Kammermusik oder größere Vokalwerke hinterlassen haben – Brahms, Schumann, Schubert –, blieben im Repertoire präsent. Franz nicht.

* '''Kein zyklisches Hauptwerk:''' Anders als Schubert mit der ''Winterreise'' oder der ''Schönen Müllerin'' hinterließ Franz keinen Liederzyklus, der als geschlossenes Abendprogramm funktioniert und vermarktbar ist.

* '''Kein überregionales Netzwerk:''' Franz lebte und arbeitete sein Leben lang in Halle. Er hatte keine Schüler, die seine Tradition weitergetragen hätten, und keine Präsenz in den großen Musikzentren Wien, Leipzig oder Berlin.

* '''Die Taubheit:''' 25 Jahre Isolation am Ende seines Lebens bedeuteten: kein Spätwerk, keine Weiterentwicklung, keine späten Meisterwerke wie bei Beethoven oder Schubert.

Schumann hatte Franz übrigens bereits früh ermahnt, sich nicht auf das Lied zu beschränken. Franz blieb trotzdem bei seiner Wahl – konsequent und ohne Kompromisse. Das verdient Respekt, auch wenn es seinen Nachruhm gekostet hat.

== Zeitgenössische Wertschätzung ==

Dass Franz zu Lebzeiten keineswegs unbekannt war, zeigt eine Episode aus dem Jahr 1873: Als seine finanzielle Lage nach dem Verlust seiner Ämter und Bezüge prekär wurde, organisierten Franz Liszt und andere namhafte Musikerpersönlichkeiten einen Ehrenfonds, der Franz den Lebensunterhalt sicherte. Liszt hatte zudem bereits 1872 eine Monographie über Franz verfasst.

== Weblinks und Quellen ==

* [https://www.deutsche-biographie.de/sfz16975.html Deutsche Biographie – Robert Franz] (Allgemeine Deutsche Biographie, Band 48, 1904)
* [https://de.wikipedia.org/wiki/Robert_Franz Wikipedia – Robert Franz]
* [https://www.musikland-sachsenanhalt.de/beitraege/franz-robert-1815-1892/ Musikland Sachsen-Anhalt – Robert Franz]
* [https://halle.de/kultur-tourismus/stadtgeschichte/bekannte-persoenlichkeiten/beruehmte-hallenser/details/franz-robert Berühmte Hallenser – Stadt Halle]
* [https://st.museum-digital.de/object/1102 Brief von Robert Franz an Julius Schäffer, 1. Februar 1871] – Stiftung Händel-Haus Halle (museum-digital Sachsen-Anhalt)
* [https://www.klassik-heute.com/4daction/www_komponist?id=43036&bio= Klassik Heute – Biographie Robert Franz]

----
''Seite erstellt im Kontext eines Konzertprogramms mit Liedern von Robert Franz, Mai 2026.''

Robert Franz (1815-1892), deutscher Komponist

2026-05-27T12:35:49Z

Admin: /* Krankheit und Rückzug */

{{DISPLAYTITLE:Robert Franz}}
[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]

'''Robert Franz''' (eigentlich Robert Franz Julius Knauth; * 28. Juni 1815 in Halle an der Saale; † 24. Oktober 1892 ebenda) war ein deutscher Komponist, Organist und Dirigent. Er gilt als einer der bedeutendsten Liedkomponisten der deutschen Romantik – und gehört gleichzeitig zu den am stärksten vergessenen.

[[Datei:Robert Franz.jpg|thumb|right|250px|Robert Franz (1815–1892)]]

== Leben ==

=== Herkunft und Ausbildung ===

Robert Franz stammte aus einer alteingesessenen Hallorer-Familie. (Siehe auch: [[Halloren]]).
Er wuchs in Halle auf, wo er ab 1828 die Latina der Franckeschen Stiftungen besuchte. Früh fiel er durch musikalische Begabung auf; der dortige Kantor Carl Gottlob Abela ließ ihn die Proben des Schulchors am Klavier begleiten. Von 1835 bis 1837 studierte er Komposition bei Friedrich Schneider in Dessau und kehrte danach nach Halle zurück – in eine Stadt, die er zeit seines Lebens kaum verlassen sollte.

=== Berufliche Laufbahn in Halle ===

Nach schwierigen wirtschaftlichen Anfangsjahren übernahm Franz 1841 das Organistenamt an der Ulrichskirche. Im folgenden Jahr wurde er Dirigent der Singakademie Halle, die später seinen Namen annahm. 1848 heiratete er Marie Hinrichs, Tochter eines Professors und selbst Komponistin; das Paar hatte drei Kinder. 1859 wurde Franz schließlich zum Universitätsmusikdirektor ernannt – der Höhepunkt seiner öffentlichen Laufbahn.

=== Krankheit und Rückzug ===

Seit 1843 litt Franz an einem Nerven- und Ohrenleiden, das sich über Jahrzehnte progressiv verschlimmerte und schließlich zur vollständigen Taubheit führte. 1867 wurde er beurlaubt,
1868 musste er alle Ämter endgültig aufgeben. Die daraus folgende finanzielle Not war erheblich: Ein 1867 zuerkannter Ehrensold wurde ihm 1877 auf Betreiben von Widersachern wieder entzogen. Seinen Lebensunterhalt sicherte schließlich ein 1873 von Freunden und Kollegen – allen voran Franz Liszt – gestifteter Ehrenfonds in Höhe von 30.000 Talern.

Die letzten rund 25 Jahre seines Lebens verbrachte Franz in nahezu vollständiger Taubheit und sozialem Rückzug. Er starb am 24. Oktober 1892 in Halle.

1885 wurde ihm zu seinem 70. Geburtstag – anlässlich der Feier des 200. Geburtstags Georg Friedrich Händels – das Ehrenbürgerrecht der Stadt Halle verliehen.

[[Datei:robert-franz-im-alter.jpg|thumb|right|250px|Robert Franz, späte Aufnahme]]

== Das Werk ==

=== Die Lieder ===

Robert Franz schrieb über 350 Kunstlieder für Singstimme und Klavier – und fast ausschließlich das. Keine Symphonien, keine Opern, kein Streichquartett. Diese bewusste Konzentration auf eine einzige Gattung war seine Stärke und zugleich der Grund für sein späteres Vergessen.

Etwa ein Viertel seiner Lieder vertont Texte von Heinrich Heine. Daneben war Karl Wilhelm Osterwald ein bevorzugter Dichter. Franz' Vertonungsweise gilt als außerordentlich textgetreu und harmonisch differenziert – ohne Effekthascherei, in großer Zurückhaltung und mit feinem Klangsinn. Robert Schumann, dem Franz 1843 sein erstes gedrucktes Heft (op. 1, ''Zwölf Gesänge'') zuschickte, antwortete, die Lieder hätten ihm gefallen „wie seit langer Zeit keine mehr". Auch Mendelssohn, Liszt und Wagner äußerten sich anerkennend.

Zu den heute noch gelegentlich aufgeführten Liedern gehören:
* ''Aus meinen großen Schmerzen'', op. 5 Nr. 1 (Text: Heinrich Heine)
* ''Auf dem Meere'', op. 5 Nr. 3 (Text: Heinrich Heine)
* ''Sterne mit den goldnen Füßchen'' (Text: Heinrich Heine)
* ''Schilflieder'', op. 2 (Text: Nikolaus Lenau)

Die Opuszahlen von ''Sterne mit den goldnen Füßchen''
konnten nicht zweifelsfrei belegt werden.

=== Bearbeitungen von Bach und Händel ===

Neben seinen Liedern hat sich Franz einen – weniger bekannten, aber musikhistorisch bedeutsamen – Namen als Bearbeiter älterer Musik erworben. Als Leiter der Singakademie brachte er Werke von Johann Sebastian Bach und Georg Friedrich Händel zur Aufführung und fertigte dafür eigene Bearbeitungen an, die den Werken eine für das 19. Jahrhundert spielbare Gestalt gaben.

Zu seinen wichtigsten Bearbeitungen zählen:
* J. S. Bach: Matthäuspassion, Magnificat, Weihnachtsoratorium, Trauerode, zahlreiche Kantaten
* G. F. Händel: Messias, Jubilate, L'Allegro il Pensieroso ed il Moderato, Arien und Duette

Diese Bearbeitungen waren unter Musikern höchst umstritten – und führten zu einem der interessantesten musikwissenschaftlichen Streits der zweiten Hälfte des 19. Jahrhunderts (siehe unten).

== Der Bearbeitungsstreit ==

Franz' Ergänzungen des barocken Generalbasssatzes – also seine Ausführung der in Barockpartituren nur skizzenhaft notierten Begleitung – stießen auf scharfen Widerspruch der aufkommenden philologisch-historischen Schule. Besonders Friedrich Chrysander, Herausgeber der Händel-Gesamtausgabe, und Philipp Spitta, der maßgebliche Bach-Forscher der Zeit, kritisierten Franz' Herangehensweise als zu romantisierend und zu wenig historisch korrekt.

Franz seinerseits ließ sich das nicht gefallen. In einem [[Brief vom 1. Februar 1871 | Brief]] an seinen Freund Julius Schäffer schrieb er über Chrysander:

: ''„Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne gepachtet zu haben."''

Der Streit wurde auch öffentlich geführt. Schäffer verfasste zwischen 1875 und 1880 eine Reihe von Streitschriften zur Verteidigung der Franz'schen Bearbeitungen, darunter ''Entgegnung auf Ph. Spitta's Artikel: Über das Accompagnement in den Kompositionen Seb. Bachs'' und ''Friedr. Chrysander in seinen Klavierauszügen zur deutschen Händel-Ausgabe''. Franz selbst meldete sich mit einem ''Offenen Brief an Eduard Hanslick'' und den ''Mitteilungen über J. S. Bachs Magnificat'' zu Wort.

Auf Seiten der Franz'schen Bearbeitungen standen namhafte Praktiker wie Liszt, Felix Mottl, Hans Richter und Arthur Nikisch. Die philologische Schule – Chrysander, Spitta – pochte auf Texttreue.

Dieser Streit ist im Kern derselbe, der bis heute nicht wirklich entschieden ist: Wie viel interpretatorische Freiheit darf – oder muss – eine lebendige Aufführung alter Musik haben? Franz stand auf der Seite der musikalischen Praxis; die Gegenseite bereitete den Boden für das vor, was später als Historisch Informierte Aufführungspraxis bekannt werden sollte.

== Warum ist Robert Franz vergessen? ==

Das ist eine berechtigte Frage – und die Antwort ist vielschichtig:

* '''Das Gattungsproblem:''' Franz schrieb fast ausschließlich Lieder. Im 20. Jahrhundert rückte das Kunstlied zunehmend an den Rand des Konzertlebens. Komponisten, die auch Symphonien, Kammermusik oder größere Vokalwerke hinterlassen haben – Brahms, Schumann, Schubert –, blieben im Repertoire präsent. Franz nicht.

* '''Kein zyklisches Hauptwerk:''' Anders als Schubert mit der ''Winterreise'' oder der ''Schönen Müllerin'' hinterließ Franz keinen Liederzyklus, der als geschlossenes Abendprogramm funktioniert und vermarktbar ist.

* '''Kein überregionales Netzwerk:''' Franz lebte und arbeitete sein Leben lang in Halle. Er hatte keine Schüler, die seine Tradition weitergetragen hätten, und keine Präsenz in den großen Musikzentren Wien, Leipzig oder Berlin.

* '''Die Taubheit:''' 25 Jahre Isolation am Ende seines Lebens bedeuteten: kein Spätwerk, keine Weiterentwicklung, keine späten Meisterwerke wie bei Beethoven oder Schubert.

Schumann hatte Franz übrigens bereits früh ermahnt, sich nicht auf das Lied zu beschränken. Franz blieb trotzdem bei seiner Wahl – konsequent und ohne Kompromisse. Das verdient Respekt, auch wenn es seinen Nachruhm gekostet hat.

== Zeitgenössische Wertschätzung ==

Dass Franz zu Lebzeiten keineswegs unbekannt war, zeigt eine Episode aus dem Jahr 1873: Als seine finanzielle Lage nach dem Verlust seiner Ämter und Bezüge prekär wurde, organisierten Franz Liszt und andere namhafte Musikerpersönlichkeiten einen Ehrenfonds, der Franz den Lebensunterhalt sicherte. Liszt hatte zudem bereits 1872 eine Monographie über Franz verfasst.

== Weblinks und Quellen ==

* [https://www.deutsche-biographie.de/sfz16975.html Deutsche Biographie – Robert Franz] (Allgemeine Deutsche Biographie, Band 48, 1904)
* [https://de.wikipedia.org/wiki/Robert_Franz Wikipedia – Robert Franz]
* [https://www.musikland-sachsenanhalt.de/beitraege/franz-robert-1815-1892/ Musikland Sachsen-Anhalt – Robert Franz]
* [https://halle.de/kultur-tourismus/stadtgeschichte/bekannte-persoenlichkeiten/beruehmte-hallenser/details/franz-robert Berühmte Hallenser – Stadt Halle]
* [https://st.museum-digital.de/object/1102 Brief von Robert Franz an Julius Schäffer, 1. Februar 1871] – Stiftung Händel-Haus Halle (museum-digital Sachsen-Anhalt)
* [https://www.klassik-heute.com/4daction/www_komponist?id=43036&bio= Klassik Heute – Biographie Robert Franz]

----
''Seite erstellt im Kontext eines Konzertprogramms mit Liedern von Robert Franz, Mai 2026.''

Robert Franz (1815-1892), deutscher Komponist

2026-05-27T12:34:47Z

Admin:

{{DISPLAYTITLE:Robert Franz}}
[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]

'''Robert Franz''' (eigentlich Robert Franz Julius Knauth; * 28. Juni 1815 in Halle an der Saale; † 24. Oktober 1892 ebenda) war ein deutscher Komponist, Organist und Dirigent. Er gilt als einer der bedeutendsten Liedkomponisten der deutschen Romantik – und gehört gleichzeitig zu den am stärksten vergessenen.

[[Datei:Robert Franz.jpg|thumb|right|250px|Robert Franz (1815–1892)]]

== Leben ==

=== Herkunft und Ausbildung ===

Robert Franz stammte aus einer alteingesessenen Hallorer-Familie. (Siehe auch: [[Halloren]]).
Er wuchs in Halle auf, wo er ab 1828 die Latina der Franckeschen Stiftungen besuchte. Früh fiel er durch musikalische Begabung auf; der dortige Kantor Carl Gottlob Abela ließ ihn die Proben des Schulchors am Klavier begleiten. Von 1835 bis 1837 studierte er Komposition bei Friedrich Schneider in Dessau und kehrte danach nach Halle zurück – in eine Stadt, die er zeit seines Lebens kaum verlassen sollte.

=== Berufliche Laufbahn in Halle ===

Nach schwierigen wirtschaftlichen Anfangsjahren übernahm Franz 1841 das Organistenamt an der Ulrichskirche. Im folgenden Jahr wurde er Dirigent der Singakademie Halle, die später seinen Namen annahm. 1848 heiratete er Marie Hinrichs, Tochter eines Professors und selbst Komponistin; das Paar hatte drei Kinder. 1859 wurde Franz schließlich zum Universitätsmusikdirektor ernannt – der Höhepunkt seiner öffentlichen Laufbahn.

=== Krankheit und Rückzug ===

Seit 1843 litt Franz an einem Nerven- und Ohrenleiden, das sich über Jahrzehnte progressiv verschlimmerte und schließlich zur vollständigen Taubheit führte. 1867 wurde er beurlaubt,
1868 musste er alle Ämter endgültig aufgeben. Die daraus folgende finanzielle Not war erheblich: Ein 1867 zuerkannter Ehrensold wurde ihm 1877 auf Betreiben von Widersachern wieder entzogen. Seinen Lebensunterhalt sicherte schließlich ein 1873 von Freunden und Kollegen – allen voran Franz Liszt – gestifteter Ehrenfonds in Höhe von 30.000 Talern.

Die letzten rund 25 Jahre seines Lebens verbrachte Franz in nahezu vollständiger Taubheit und sozialem Rückzug. Er starb am 24. Oktober 1892 in Halle.

1885 wurde ihm zu seinem 70. Geburtstag – anlässlich der Feier des 200. Geburtstags Georg Friedrich Händels – das Ehrenbürgerrecht der Stadt Halle verliehen.

== Das Werk ==

=== Die Lieder ===

Robert Franz schrieb über 350 Kunstlieder für Singstimme und Klavier – und fast ausschließlich das. Keine Symphonien, keine Opern, kein Streichquartett. Diese bewusste Konzentration auf eine einzige Gattung war seine Stärke und zugleich der Grund für sein späteres Vergessen.

Etwa ein Viertel seiner Lieder vertont Texte von Heinrich Heine. Daneben war Karl Wilhelm Osterwald ein bevorzugter Dichter. Franz' Vertonungsweise gilt als außerordentlich textgetreu und harmonisch differenziert – ohne Effekthascherei, in großer Zurückhaltung und mit feinem Klangsinn. Robert Schumann, dem Franz 1843 sein erstes gedrucktes Heft (op. 1, ''Zwölf Gesänge'') zuschickte, antwortete, die Lieder hätten ihm gefallen „wie seit langer Zeit keine mehr". Auch Mendelssohn, Liszt und Wagner äußerten sich anerkennend.

Zu den heute noch gelegentlich aufgeführten Liedern gehören:
* ''Aus meinen großen Schmerzen'', op. 5 Nr. 1 (Text: Heinrich Heine)
* ''Auf dem Meere'', op. 5 Nr. 3 (Text: Heinrich Heine)
* ''Sterne mit den goldnen Füßchen'' (Text: Heinrich Heine)
* ''Schilflieder'', op. 2 (Text: Nikolaus Lenau)

Die Opuszahlen von ''Sterne mit den goldnen Füßchen''
konnten nicht zweifelsfrei belegt werden.

=== Bearbeitungen von Bach und Händel ===

Neben seinen Liedern hat sich Franz einen – weniger bekannten, aber musikhistorisch bedeutsamen – Namen als Bearbeiter älterer Musik erworben. Als Leiter der Singakademie brachte er Werke von Johann Sebastian Bach und Georg Friedrich Händel zur Aufführung und fertigte dafür eigene Bearbeitungen an, die den Werken eine für das 19. Jahrhundert spielbare Gestalt gaben.

Zu seinen wichtigsten Bearbeitungen zählen:
* J. S. Bach: Matthäuspassion, Magnificat, Weihnachtsoratorium, Trauerode, zahlreiche Kantaten
* G. F. Händel: Messias, Jubilate, L'Allegro il Pensieroso ed il Moderato, Arien und Duette

Diese Bearbeitungen waren unter Musikern höchst umstritten – und führten zu einem der interessantesten musikwissenschaftlichen Streits der zweiten Hälfte des 19. Jahrhunderts (siehe unten).

== Der Bearbeitungsstreit ==

Franz' Ergänzungen des barocken Generalbasssatzes – also seine Ausführung der in Barockpartituren nur skizzenhaft notierten Begleitung – stießen auf scharfen Widerspruch der aufkommenden philologisch-historischen Schule. Besonders Friedrich Chrysander, Herausgeber der Händel-Gesamtausgabe, und Philipp Spitta, der maßgebliche Bach-Forscher der Zeit, kritisierten Franz' Herangehensweise als zu romantisierend und zu wenig historisch korrekt.

Franz seinerseits ließ sich das nicht gefallen. In einem [[Brief vom 1. Februar 1871 | Brief]] an seinen Freund Julius Schäffer schrieb er über Chrysander:

: ''„Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne gepachtet zu haben."''

Der Streit wurde auch öffentlich geführt. Schäffer verfasste zwischen 1875 und 1880 eine Reihe von Streitschriften zur Verteidigung der Franz'schen Bearbeitungen, darunter ''Entgegnung auf Ph. Spitta's Artikel: Über das Accompagnement in den Kompositionen Seb. Bachs'' und ''Friedr. Chrysander in seinen Klavierauszügen zur deutschen Händel-Ausgabe''. Franz selbst meldete sich mit einem ''Offenen Brief an Eduard Hanslick'' und den ''Mitteilungen über J. S. Bachs Magnificat'' zu Wort.

Auf Seiten der Franz'schen Bearbeitungen standen namhafte Praktiker wie Liszt, Felix Mottl, Hans Richter und Arthur Nikisch. Die philologische Schule – Chrysander, Spitta – pochte auf Texttreue.

Dieser Streit ist im Kern derselbe, der bis heute nicht wirklich entschieden ist: Wie viel interpretatorische Freiheit darf – oder muss – eine lebendige Aufführung alter Musik haben? Franz stand auf der Seite der musikalischen Praxis; die Gegenseite bereitete den Boden für das vor, was später als Historisch Informierte Aufführungspraxis bekannt werden sollte.

== Warum ist Robert Franz vergessen? ==

Das ist eine berechtigte Frage – und die Antwort ist vielschichtig:

* '''Das Gattungsproblem:''' Franz schrieb fast ausschließlich Lieder. Im 20. Jahrhundert rückte das Kunstlied zunehmend an den Rand des Konzertlebens. Komponisten, die auch Symphonien, Kammermusik oder größere Vokalwerke hinterlassen haben – Brahms, Schumann, Schubert –, blieben im Repertoire präsent. Franz nicht.

* '''Kein zyklisches Hauptwerk:''' Anders als Schubert mit der ''Winterreise'' oder der ''Schönen Müllerin'' hinterließ Franz keinen Liederzyklus, der als geschlossenes Abendprogramm funktioniert und vermarktbar ist.

* '''Kein überregionales Netzwerk:''' Franz lebte und arbeitete sein Leben lang in Halle. Er hatte keine Schüler, die seine Tradition weitergetragen hätten, und keine Präsenz in den großen Musikzentren Wien, Leipzig oder Berlin.

* '''Die Taubheit:''' 25 Jahre Isolation am Ende seines Lebens bedeuteten: kein Spätwerk, keine Weiterentwicklung, keine späten Meisterwerke wie bei Beethoven oder Schubert.

Schumann hatte Franz übrigens bereits früh ermahnt, sich nicht auf das Lied zu beschränken. Franz blieb trotzdem bei seiner Wahl – konsequent und ohne Kompromisse. Das verdient Respekt, auch wenn es seinen Nachruhm gekostet hat.

== Zeitgenössische Wertschätzung ==

Dass Franz zu Lebzeiten keineswegs unbekannt war, zeigt eine Episode aus dem Jahr 1873: Als seine finanzielle Lage nach dem Verlust seiner Ämter und Bezüge prekär wurde, organisierten Franz Liszt und andere namhafte Musikerpersönlichkeiten einen Ehrenfonds, der Franz den Lebensunterhalt sicherte. Liszt hatte zudem bereits 1872 eine Monographie über Franz verfasst.

== Weblinks und Quellen ==

* [https://www.deutsche-biographie.de/sfz16975.html Deutsche Biographie – Robert Franz] (Allgemeine Deutsche Biographie, Band 48, 1904)
* [https://de.wikipedia.org/wiki/Robert_Franz Wikipedia – Robert Franz]
* [https://www.musikland-sachsenanhalt.de/beitraege/franz-robert-1815-1892/ Musikland Sachsen-Anhalt – Robert Franz]
* [https://halle.de/kultur-tourismus/stadtgeschichte/bekannte-persoenlichkeiten/beruehmte-hallenser/details/franz-robert Berühmte Hallenser – Stadt Halle]
* [https://st.museum-digital.de/object/1102 Brief von Robert Franz an Julius Schäffer, 1. Februar 1871] – Stiftung Händel-Haus Halle (museum-digital Sachsen-Anhalt)
* [https://www.klassik-heute.com/4daction/www_komponist?id=43036&bio= Klassik Heute – Biographie Robert Franz]

----
''Seite erstellt im Kontext eines Konzertprogramms mit Liedern von Robert Franz, Mai 2026.''

Datei:Robert Franz.jpg

2026-05-27T12:33:08Z

Admin: https://commons.wikimedia.org/wiki/File:Robert_Franz.jpg

== Beschreibung ==
https://commons.wikimedia.org/wiki/File:Robert_Franz.jpg

Datei:Robert-franz-im-alter.png

2026-05-27T12:31:03Z

Admin: https://www.britannica.com/biography/Robert-Franz#/media/1/217464/10794

== Beschreibung ==
https://www.britannica.com/biography/Robert-Franz#/media/1/217464/10794

Robert Franz (1815-1892), deutscher Komponist

2026-05-27T12:23:01Z

Admin: /* Der Bearbeitungsstreit */

{{DISPLAYTITLE:Robert Franz}}
[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]

'''Robert Franz''' (eigentlich Robert Franz Julius Knauth; * 28. Juni 1815 in Halle an der Saale; † 24. Oktober 1892 ebenda) war ein deutscher Komponist, Organist und Dirigent. Er gilt als einer der bedeutendsten Liedkomponisten der deutschen Romantik – und gehört gleichzeitig zu den am stärksten vergessenen.

== Leben ==

=== Herkunft und Ausbildung ===

Robert Franz stammte aus einer alteingesessenen Hallorer-Familie. (Siehe auch: [[Halloren]]).
Er wuchs in Halle auf, wo er ab 1828 die Latina der Franckeschen Stiftungen besuchte. Früh fiel er durch musikalische Begabung auf; der dortige Kantor Carl Gottlob Abela ließ ihn die Proben des Schulchors am Klavier begleiten. Von 1835 bis 1837 studierte er Komposition bei Friedrich Schneider in Dessau und kehrte danach nach Halle zurück – in eine Stadt, die er zeit seines Lebens kaum verlassen sollte.

=== Berufliche Laufbahn in Halle ===

Nach schwierigen wirtschaftlichen Anfangsjahren übernahm Franz 1841 das Organistenamt an der Ulrichskirche. Im folgenden Jahr wurde er Dirigent der Singakademie Halle, die später seinen Namen annahm. 1848 heiratete er Marie Hinrichs, Tochter eines Professors und selbst Komponistin; das Paar hatte drei Kinder. 1859 wurde Franz schließlich zum Universitätsmusikdirektor ernannt – der Höhepunkt seiner öffentlichen Laufbahn.

=== Krankheit und Rückzug ===

Seit 1843 litt Franz an einem Nerven- und Ohrenleiden, das sich über Jahrzehnte progressiv verschlimmerte und schließlich zur vollständigen Taubheit führte. 1867 wurde er beurlaubt,
1868 musste er alle Ämter endgültig aufgeben. Die daraus folgende finanzielle Not war erheblich: Ein 1867 zuerkannter Ehrensold wurde ihm 1877 auf Betreiben von Widersachern wieder entzogen. Seinen Lebensunterhalt sicherte schließlich ein 1873 von Freunden und Kollegen – allen voran Franz Liszt – gestifteter Ehrenfonds in Höhe von 30.000 Talern.

Die letzten rund 25 Jahre seines Lebens verbrachte Franz in nahezu vollständiger Taubheit und sozialem Rückzug. Er starb am 24. Oktober 1892 in Halle.

1885 wurde ihm zu seinem 70. Geburtstag – anlässlich der Feier des 200. Geburtstags Georg Friedrich Händels – das Ehrenbürgerrecht der Stadt Halle verliehen.

== Das Werk ==

=== Die Lieder ===

Robert Franz schrieb über 350 Kunstlieder für Singstimme und Klavier – und fast ausschließlich das. Keine Symphonien, keine Opern, kein Streichquartett. Diese bewusste Konzentration auf eine einzige Gattung war seine Stärke und zugleich der Grund für sein späteres Vergessen.

Etwa ein Viertel seiner Lieder vertont Texte von Heinrich Heine. Daneben war Karl Wilhelm Osterwald ein bevorzugter Dichter. Franz' Vertonungsweise gilt als außerordentlich textgetreu und harmonisch differenziert – ohne Effekthascherei, in großer Zurückhaltung und mit feinem Klangsinn. Robert Schumann, dem Franz 1843 sein erstes gedrucktes Heft (op. 1, ''Zwölf Gesänge'') zuschickte, antwortete, die Lieder hätten ihm gefallen „wie seit langer Zeit keine mehr". Auch Mendelssohn, Liszt und Wagner äußerten sich anerkennend.

Zu den heute noch gelegentlich aufgeführten Liedern gehören:
* ''Aus meinen großen Schmerzen'', op. 5 Nr. 1 (Text: Heinrich Heine)
* ''Auf dem Meere'', op. 5 Nr. 3 (Text: Heinrich Heine)
* ''Sterne mit den goldnen Füßchen'' (Text: Heinrich Heine)
* ''Schilflieder'', op. 2 (Text: Nikolaus Lenau)

Die Opuszahlen von ''Sterne mit den goldnen Füßchen''
konnten nicht zweifelsfrei belegt werden.

=== Bearbeitungen von Bach und Händel ===

Neben seinen Liedern hat sich Franz einen – weniger bekannten, aber musikhistorisch bedeutsamen – Namen als Bearbeiter älterer Musik erworben. Als Leiter der Singakademie brachte er Werke von Johann Sebastian Bach und Georg Friedrich Händel zur Aufführung und fertigte dafür eigene Bearbeitungen an, die den Werken eine für das 19. Jahrhundert spielbare Gestalt gaben.

Zu seinen wichtigsten Bearbeitungen zählen:
* J. S. Bach: Matthäuspassion, Magnificat, Weihnachtsoratorium, Trauerode, zahlreiche Kantaten
* G. F. Händel: Messias, Jubilate, L'Allegro il Pensieroso ed il Moderato, Arien und Duette

Diese Bearbeitungen waren unter Musikern höchst umstritten – und führten zu einem der interessantesten musikwissenschaftlichen Streits der zweiten Hälfte des 19. Jahrhunderts (siehe unten).

== Der Bearbeitungsstreit ==

Franz' Ergänzungen des barocken Generalbasssatzes – also seine Ausführung der in Barockpartituren nur skizzenhaft notierten Begleitung – stießen auf scharfen Widerspruch der aufkommenden philologisch-historischen Schule. Besonders Friedrich Chrysander, Herausgeber der Händel-Gesamtausgabe, und Philipp Spitta, der maßgebliche Bach-Forscher der Zeit, kritisierten Franz' Herangehensweise als zu romantisierend und zu wenig historisch korrekt.

Franz seinerseits ließ sich das nicht gefallen. In einem [[Brief vom 1. Februar 1871 | Brief]] an seinen Freund Julius Schäffer schrieb er über Chrysander:

: ''„Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne gepachtet zu haben."''

Der Streit wurde auch öffentlich geführt. Schäffer verfasste zwischen 1875 und 1880 eine Reihe von Streitschriften zur Verteidigung der Franz'schen Bearbeitungen, darunter ''Entgegnung auf Ph. Spitta's Artikel: Über das Accompagnement in den Kompositionen Seb. Bachs'' und ''Friedr. Chrysander in seinen Klavierauszügen zur deutschen Händel-Ausgabe''. Franz selbst meldete sich mit einem ''Offenen Brief an Eduard Hanslick'' und den ''Mitteilungen über J. S. Bachs Magnificat'' zu Wort.

Auf Seiten der Franz'schen Bearbeitungen standen namhafte Praktiker wie Liszt, Felix Mottl, Hans Richter und Arthur Nikisch. Die philologische Schule – Chrysander, Spitta – pochte auf Texttreue.

Dieser Streit ist im Kern derselbe, der bis heute nicht wirklich entschieden ist: Wie viel interpretatorische Freiheit darf – oder muss – eine lebendige Aufführung alter Musik haben? Franz stand auf der Seite der musikalischen Praxis; die Gegenseite bereitete den Boden für das vor, was später als Historisch Informierte Aufführungspraxis bekannt werden sollte.

== Warum ist Robert Franz vergessen? ==

Das ist eine berechtigte Frage – und die Antwort ist vielschichtig:

* '''Das Gattungsproblem:''' Franz schrieb fast ausschließlich Lieder. Im 20. Jahrhundert rückte das Kunstlied zunehmend an den Rand des Konzertlebens. Komponisten, die auch Symphonien, Kammermusik oder größere Vokalwerke hinterlassen haben – Brahms, Schumann, Schubert –, blieben im Repertoire präsent. Franz nicht.

* '''Kein zyklisches Hauptwerk:''' Anders als Schubert mit der ''Winterreise'' oder der ''Schönen Müllerin'' hinterließ Franz keinen Liederzyklus, der als geschlossenes Abendprogramm funktioniert und vermarktbar ist.

* '''Kein überregionales Netzwerk:''' Franz lebte und arbeitete sein Leben lang in Halle. Er hatte keine Schüler, die seine Tradition weitergetragen hätten, und keine Präsenz in den großen Musikzentren Wien, Leipzig oder Berlin.

* '''Die Taubheit:''' 25 Jahre Isolation am Ende seines Lebens bedeuteten: kein Spätwerk, keine Weiterentwicklung, keine späten Meisterwerke wie bei Beethoven oder Schubert.

Schumann hatte Franz übrigens bereits früh ermahnt, sich nicht auf das Lied zu beschränken. Franz blieb trotzdem bei seiner Wahl – konsequent und ohne Kompromisse. Das verdient Respekt, auch wenn es seinen Nachruhm gekostet hat.

== Zeitgenössische Wertschätzung ==

Dass Franz zu Lebzeiten keineswegs unbekannt war, zeigt eine Episode aus dem Jahr 1873: Als seine finanzielle Lage nach dem Verlust seiner Ämter und Bezüge prekär wurde, organisierten Franz Liszt und andere namhafte Musikerpersönlichkeiten einen Ehrenfonds, der Franz den Lebensunterhalt sicherte. Liszt hatte zudem bereits 1872 eine Monographie über Franz verfasst.

== Weblinks und Quellen ==

* [https://www.deutsche-biographie.de/sfz16975.html Deutsche Biographie – Robert Franz] (Allgemeine Deutsche Biographie, Band 48, 1904)
* [https://de.wikipedia.org/wiki/Robert_Franz Wikipedia – Robert Franz]
* [https://www.musikland-sachsenanhalt.de/beitraege/franz-robert-1815-1892/ Musikland Sachsen-Anhalt – Robert Franz]
* [https://halle.de/kultur-tourismus/stadtgeschichte/bekannte-persoenlichkeiten/beruehmte-hallenser/details/franz-robert Berühmte Hallenser – Stadt Halle]
* [https://st.museum-digital.de/object/1102 Brief von Robert Franz an Julius Schäffer, 1. Februar 1871] – Stiftung Händel-Haus Halle (museum-digital Sachsen-Anhalt)
* [https://www.klassik-heute.com/4daction/www_komponist?id=43036&bio= Klassik Heute – Biographie Robert Franz]

----
''Seite erstellt im Kontext eines Konzertprogramms mit Liedern von Robert Franz, Mai 2026.''

Brief vom 1. Februar 1871

2026-05-27T12:22:26Z

Admin: /* Brief von Robert Franz an Julius Schäffer, 1. Februar 1871 */

[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]
[[Kategorie:Quellen]]

== Brief von Robert Franz an Julius Schäffer, 1. Februar 1871 ==

Dieser Brief entstand zu einem für [[Robert Franz (1815-1892), deutscher Komponist | Robert Franz]] schwierigen
Zeitpunkt: Seit 1867 beurlaubt, seit 1868 ohne alle Ämter,
zunehmend taub und finanziell bedrängt – und dennoch alles andere
als resigniert.

Adressat ist Julius Schäffer (1823–1902), Universitätsmusikdirektor
in Breslau, Schüler und enger Freund von Franz, der ihn in den
folgenden Jahren in der öffentlichen Auseinandersetzung um die
Bearbeitungsfrage tatkräftig verteidigte.

Der Brief zeigt Franz in unverstellter Deutlichkeit: Die
Formulierungen über Friedrich Chrysander lassen an Klarheit nichts
zu wünschen übrig.

Quelle: [https://st.museum-digital.de/object/1102
Stiftung Händel-Haus Halle, museum-digital Sachsen-Anhalt]

----

== Brieftext ==

Bester Schäffer!
In meinem letzten Briefe wollte ich mich nur bei Ihnen wieder einmal in Erinnerung bringen. Es versteht sich von selbst, daß Ihre Concerte keinen anderen Verlauf nehmen können, als ihn die Verhältnisse vorschreiben. Läßt sich aber gelegentlich eine Einlage im Interesse meiner Arbeiten bewerkstelligen, so wird es mir sehr lieb sein, wenn Sie an mich denken. -

Chrysanders Notizen über meine Publicationen haben mich, ich kann es nicht leugnen, in eine gelinde Wuth versetzt. Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne[?] gepachtet zu haben. Des Kerls Perfidie ist um so größer, als er mich vor einigen Jahren direkt zur Mitwirkung bei seinen "Denkmalen der Kunst" zu veranlassen suchte. Damals hatte ich bereits einen großen Haufen Bach'scher Werke bearbeitet u. Chrysander mußte doch wissen, was von mir zu erwarten stand. Aus mancherlei Gründen schlug ich den Antrag ab u. jetzt stellt sich der Bursche an, als versündigte ich mich geradezu an den alten Meistern. Wie sich ein honetter[?] Künstler dazu hergeben kann, sich von so einem ausrangirten Philologen in's Schlepptau nehmen zu lassen, ist schwer zu begreifen. Leider steht's aber mit der künstlerischen Respektabilität heut zu Tage schlecht genug, wie Sie das z. B. an den Brahms'schen Bearbeitungen der Kammerduette recht augenfällig wahrnehmen können. Um Dresel einen harmlosen Scherz zu bereiten, ging ich einige Stündchen auf die Quinten u. Octavenjagd - wie ich ein volles Schock (wörtlich zu nehmen) gespießt hatte, wurde mir die Geschichte doch gar zu langweilig u. ich klappte den Bettel[?] zu. Und mit solchem Schunde, der dem ersten besten Schuljungen Schande machen müßte, wagt es Herr Chrysander, seine Ausgaben aufzuputzen. Aber auch ganz abgesehen von der stinkenden Unsauberkeit des Tonsatzes, tragen diese Fabrikate den Stempel völliger Impotenz an der Stirn: nirgends ist ein Schimmer von Stimmung herausgedrückst[?] worden. Sollte mir unser Herr Redakteur etwa in die Quere kommen, dann reibe ich ihm, dem Mitverantwortlichen, jenes volle Schock meiner Flohjagd, dessen Spießung denn noch nicht ganz überflüssig war, derb unter die Nase. Angesichts solcher Erbärmlichkeiten wird aber eine Redensart wie: "wir könnten dem Manne dann helfen u. Freude bereiten" schlechterdings beleidigend. Der Esel hat ja nicht die geringste Vorstellung von dem eigentlichen Kernpunkte meiner Arbeiten. Diese werden hoffentlich dazu beitragen, den Leuten früher oder später über Händel'sche Art die Augen zu öffnen, während die öden Dudeleien jener Pfuscher nothwendig den Erfolg haben, des großen Mannes allgemeinere Anerkennung zu hintertreiben u. in weite Ferne hinauszuschieben. Besehe ich die Sache recht bei Lichte, so wird mir's immer klarer, daß Chrysander von dem coloss[a]len Ehrgeize besessen ist, mutterseelenallein die Rehabilitirung Händel's in's Werk setzen zu wollen. Offenbar genügen ihm die Triumphe auf dem Feld der Geschichte nicht mehr - er beabsichtigt auch "in Kunst" zu machen. Um seinen Schund aber an den Mann bringen zu können, muß er zuvor Besseres zu discreditiren suchen. Darum bleibt der Messias so lange aus, darum wurde in den Jahrbüchern für Musik der Schandartikel gegen Mendelssohn geschrieben, nur darum verdächtigt er jetzt heimlich meine Arbeiten. Auch Seb. Bach steht dem Kerl im Wege: die giftigen u. heimtückischen Angriffe zeigen es deutlich genug. Die Luft des 19.ten Jahrhunderts muß aber wahrlich von Elementen strotzen, die zur blinden Selbstanbetung nöthigen: es wäre sonst gar nicht zu begreifen, daß selbst die nüchternsten Gesellen diesem unseligen Cultus zur Beute fielen! -

Ob ich Ihnen schon von meinem kleinen Rencontre, das ich vorigen Herbst in Leipzig mit dem Herren v. Dommer hatte, vorplauderte, weiß ich nicht mehr recht. Der ist auch von einem possirlichen Dünkel angefressen[?], u. brütet fauchend auf seinen historischen Windeiern. Zu meinem gränzenlosen Erstaunen erfuhr ich da, daß es beim Accompagniment lediglich darauf ankäme, sich des Cembalo und der Orgel zu bedienen. Als ich dagegen in erster Linie einen stimmungsvollen u. reinen Tonsatz verlangte, schüttelte er lächelnd das Köpflein u. erklärte dergleichen für die größte Nebensache. In meiner Angst berief ich mich auf die vielen von mir angefertigten Clavierauszüge: man könne ja dieselben für Orgel u. Cembalo, wenn man überhaupt mit Bestimmtheit anzugeben wüsste, wo erstere u. wo letzeres einzutreten hätten, ausnutzen. Die wären wieder viel zu schwer gesetzt u. darum nicht im Geiste der alten Meister, orakelte der Mann. Kurzum, ich mochte es anfangen, wie ich wollte, er blieb selbstgefällig glucksend auf seinem Strohneste hocken. Endlich erbot er sich sogar, mir schriftlich ausführlicher Belehrung über meine Arbeiten zugehen lassen zu wollen. Auf meine Aeußerung hin, daß mir theoretische Belehrungen wenig nützen könnten, wenn sie nicht zugleich positive Berichtigungen des incriminirten Satzes brächten, erklärte er ganz naiv, dies nicht zu vermögen. Darauf ließ ich den trocknen Peter[?] stehen u. ging meiner Wege, überzeugt, einen neuen Widersacher gewonnen zu haben. Uebrigens erfuhr ich bei der Gelegenheit von Dommer, daß er zwar in Kunstdingen noch immer sehr mit Chrysander harmonire - Keineswegs aber in persönlichen. Er gab ihm die ehrenrührigsten Titulaturen, die ich hier gar nicht wiederholen mag. Sie werden also weise handeln, wenn Sie sich mit dem zweideutigen Patron nur so weit befassen, als unumgänglich nothwendig ist. -

Ueber die vier bis fünhundert kleinen Veränderungen, von denen Ihr Dr. Baumgart so verzückt in Chrysander's Zeitung redet, habe ich mich auch königlich amüsirt. Unsere Historiker nehmen überall die Miene an, als seien sie vom Schicksal ganz expreß[?] zu Anwalten der verfolgten Unschuld bestimmt. Gewöhnlich ist es aber eine verschobene Busenschleife oder eine gekrümmte Stecknadel, die sie dermaßen in Eifer bringt, daß sie über solche Lappalien die Hauptsache völlig aus den Augen verlieren. Der Herr v. Gugler wollte zum Don Juan vor allem Anderen einen guten deutschen Text liefern - der ist kläglich mißrathen u. somit hat er nur dazu beigetragen, die bereits herrschende Verwirrung über Mozart's Meisterwerk zu vermehren. Doch lassen wir diese Schulfuchser auf sich beruhen, wir werden sie doch nicht ändern!-

Sehr lieb wäre es mir, wenn Dresel Ihrer Aufführung der Passion beiwohnen könnte. Er hat noch immer seine Scrupel über Klang u. Ausführbarkeit meiner Partitur. So setzte ihm z. B. Ehren-David den Floh ins Ohr, daß ich die Posaunen zu hoch führe, verschwieg aber dabei wohlweislich die heitere Thatsache, wie man in Leipzig nur mit 3 Tenorposaunen (!!!) zu wirthschaften pflege. - Die Differenzen mit Dresel lassen sich nicht gut ausgleichen, weil wir die letzten Ziele der Kunst mit gar zu verschiedenen Augen ansehen. Während ich mich nach Kräften bemühe, vom Einzelnen zum Ganzen vorzudringen, bleibt er durchschnittlich[?] in jenem stecken u. hält dieses für pure Illusion. Doch haben wir die Fehde über dergleichen Dinge suspendirt u. verkehren nur noch in rein musikalischen Fragen. Je mehr ich Dresel zu danken habe, umso fataler sind mir diese kleinen Zerwürfnisse, über die ich Sie übrigens dringend zu schweigen bitte. So wußte er neuerdings Sander zu bestimmen, den Allegro doch in Verlag zu nehmen, ein Entschluß, der mir eine Centnerlast von der Brust nimmt. Die Partitur wird im Laufe des Sommers gestochen u. soll, nebst Clavierauszug u. Stimmen zum nächsten Herbst ausgegeben werden. -

Wenn Sie Dresel in zwei Worten zur Aufführung der Passion einladen wollten, würden Sie mich sehr verbinden: dann kommt er sicherlich. Seine Adresse ist: Herren Otto Dresel in Leipzig (Hôtel zur Stadt Dresden). Auf alle Fälle zeigen Sie mir aber den Tag der Aufführung an - ich werde dann meinerseits bei Dresel nachhelfen. Wenn nur Ihre Blasinstrumente leidlich sind - das Uebrige findet sich schon. -
Doch nun leben Sie recht wohl u. seien Sie schönstens gegrüßt.
Ihr[?] Rob. Franz.
Halle d. 1.ten Febr. 71.

Brief vom 1. Februar 1871

2026-05-27T12:21:51Z

Admin: /* Brief von Robert Franz an Julius Schäffer, 1. Februar 1871 */

[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]
[[Kategorie:Quellen]]

== Brief von Robert Franz an Julius Schäffer, 1. Februar 1871 ==

Dieser Brief entstand zu einem für [[Robert Franz | Robert Franz (1815-1892), deutscher Komponist]] schwierigen
Zeitpunkt: Seit 1867 beurlaubt, seit 1868 ohne alle Ämter,
zunehmend taub und finanziell bedrängt – und dennoch alles andere
als resigniert.

Adressat ist Julius Schäffer (1823–1902), Universitätsmusikdirektor
in Breslau, Schüler und enger Freund von Franz, der ihn in den
folgenden Jahren in der öffentlichen Auseinandersetzung um die
Bearbeitungsfrage tatkräftig verteidigte.

Der Brief zeigt Franz in unverstellter Deutlichkeit: Die
Formulierungen über Friedrich Chrysander lassen an Klarheit nichts
zu wünschen übrig.

Quelle: [https://st.museum-digital.de/object/1102
Stiftung Händel-Haus Halle, museum-digital Sachsen-Anhalt]

----

== Brieftext ==

Bester Schäffer!
In meinem letzten Briefe wollte ich mich nur bei Ihnen wieder einmal in Erinnerung bringen. Es versteht sich von selbst, daß Ihre Concerte keinen anderen Verlauf nehmen können, als ihn die Verhältnisse vorschreiben. Läßt sich aber gelegentlich eine Einlage im Interesse meiner Arbeiten bewerkstelligen, so wird es mir sehr lieb sein, wenn Sie an mich denken. -

Chrysanders Notizen über meine Publicationen haben mich, ich kann es nicht leugnen, in eine gelinde Wuth versetzt. Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne[?] gepachtet zu haben. Des Kerls Perfidie ist um so größer, als er mich vor einigen Jahren direkt zur Mitwirkung bei seinen "Denkmalen der Kunst" zu veranlassen suchte. Damals hatte ich bereits einen großen Haufen Bach'scher Werke bearbeitet u. Chrysander mußte doch wissen, was von mir zu erwarten stand. Aus mancherlei Gründen schlug ich den Antrag ab u. jetzt stellt sich der Bursche an, als versündigte ich mich geradezu an den alten Meistern. Wie sich ein honetter[?] Künstler dazu hergeben kann, sich von so einem ausrangirten Philologen in's Schlepptau nehmen zu lassen, ist schwer zu begreifen. Leider steht's aber mit der künstlerischen Respektabilität heut zu Tage schlecht genug, wie Sie das z. B. an den Brahms'schen Bearbeitungen der Kammerduette recht augenfällig wahrnehmen können. Um Dresel einen harmlosen Scherz zu bereiten, ging ich einige Stündchen auf die Quinten u. Octavenjagd - wie ich ein volles Schock (wörtlich zu nehmen) gespießt hatte, wurde mir die Geschichte doch gar zu langweilig u. ich klappte den Bettel[?] zu. Und mit solchem Schunde, der dem ersten besten Schuljungen Schande machen müßte, wagt es Herr Chrysander, seine Ausgaben aufzuputzen. Aber auch ganz abgesehen von der stinkenden Unsauberkeit des Tonsatzes, tragen diese Fabrikate den Stempel völliger Impotenz an der Stirn: nirgends ist ein Schimmer von Stimmung herausgedrückst[?] worden. Sollte mir unser Herr Redakteur etwa in die Quere kommen, dann reibe ich ihm, dem Mitverantwortlichen, jenes volle Schock meiner Flohjagd, dessen Spießung denn noch nicht ganz überflüssig war, derb unter die Nase. Angesichts solcher Erbärmlichkeiten wird aber eine Redensart wie: "wir könnten dem Manne dann helfen u. Freude bereiten" schlechterdings beleidigend. Der Esel hat ja nicht die geringste Vorstellung von dem eigentlichen Kernpunkte meiner Arbeiten. Diese werden hoffentlich dazu beitragen, den Leuten früher oder später über Händel'sche Art die Augen zu öffnen, während die öden Dudeleien jener Pfuscher nothwendig den Erfolg haben, des großen Mannes allgemeinere Anerkennung zu hintertreiben u. in weite Ferne hinauszuschieben. Besehe ich die Sache recht bei Lichte, so wird mir's immer klarer, daß Chrysander von dem coloss[a]len Ehrgeize besessen ist, mutterseelenallein die Rehabilitirung Händel's in's Werk setzen zu wollen. Offenbar genügen ihm die Triumphe auf dem Feld der Geschichte nicht mehr - er beabsichtigt auch "in Kunst" zu machen. Um seinen Schund aber an den Mann bringen zu können, muß er zuvor Besseres zu discreditiren suchen. Darum bleibt der Messias so lange aus, darum wurde in den Jahrbüchern für Musik der Schandartikel gegen Mendelssohn geschrieben, nur darum verdächtigt er jetzt heimlich meine Arbeiten. Auch Seb. Bach steht dem Kerl im Wege: die giftigen u. heimtückischen Angriffe zeigen es deutlich genug. Die Luft des 19.ten Jahrhunderts muß aber wahrlich von Elementen strotzen, die zur blinden Selbstanbetung nöthigen: es wäre sonst gar nicht zu begreifen, daß selbst die nüchternsten Gesellen diesem unseligen Cultus zur Beute fielen! -

Ob ich Ihnen schon von meinem kleinen Rencontre, das ich vorigen Herbst in Leipzig mit dem Herren v. Dommer hatte, vorplauderte, weiß ich nicht mehr recht. Der ist auch von einem possirlichen Dünkel angefressen[?], u. brütet fauchend auf seinen historischen Windeiern. Zu meinem gränzenlosen Erstaunen erfuhr ich da, daß es beim Accompagniment lediglich darauf ankäme, sich des Cembalo und der Orgel zu bedienen. Als ich dagegen in erster Linie einen stimmungsvollen u. reinen Tonsatz verlangte, schüttelte er lächelnd das Köpflein u. erklärte dergleichen für die größte Nebensache. In meiner Angst berief ich mich auf die vielen von mir angefertigten Clavierauszüge: man könne ja dieselben für Orgel u. Cembalo, wenn man überhaupt mit Bestimmtheit anzugeben wüsste, wo erstere u. wo letzeres einzutreten hätten, ausnutzen. Die wären wieder viel zu schwer gesetzt u. darum nicht im Geiste der alten Meister, orakelte der Mann. Kurzum, ich mochte es anfangen, wie ich wollte, er blieb selbstgefällig glucksend auf seinem Strohneste hocken. Endlich erbot er sich sogar, mir schriftlich ausführlicher Belehrung über meine Arbeiten zugehen lassen zu wollen. Auf meine Aeußerung hin, daß mir theoretische Belehrungen wenig nützen könnten, wenn sie nicht zugleich positive Berichtigungen des incriminirten Satzes brächten, erklärte er ganz naiv, dies nicht zu vermögen. Darauf ließ ich den trocknen Peter[?] stehen u. ging meiner Wege, überzeugt, einen neuen Widersacher gewonnen zu haben. Uebrigens erfuhr ich bei der Gelegenheit von Dommer, daß er zwar in Kunstdingen noch immer sehr mit Chrysander harmonire - Keineswegs aber in persönlichen. Er gab ihm die ehrenrührigsten Titulaturen, die ich hier gar nicht wiederholen mag. Sie werden also weise handeln, wenn Sie sich mit dem zweideutigen Patron nur so weit befassen, als unumgänglich nothwendig ist. -

Ueber die vier bis fünhundert kleinen Veränderungen, von denen Ihr Dr. Baumgart so verzückt in Chrysander's Zeitung redet, habe ich mich auch königlich amüsirt. Unsere Historiker nehmen überall die Miene an, als seien sie vom Schicksal ganz expreß[?] zu Anwalten der verfolgten Unschuld bestimmt. Gewöhnlich ist es aber eine verschobene Busenschleife oder eine gekrümmte Stecknadel, die sie dermaßen in Eifer bringt, daß sie über solche Lappalien die Hauptsache völlig aus den Augen verlieren. Der Herr v. Gugler wollte zum Don Juan vor allem Anderen einen guten deutschen Text liefern - der ist kläglich mißrathen u. somit hat er nur dazu beigetragen, die bereits herrschende Verwirrung über Mozart's Meisterwerk zu vermehren. Doch lassen wir diese Schulfuchser auf sich beruhen, wir werden sie doch nicht ändern!-

Sehr lieb wäre es mir, wenn Dresel Ihrer Aufführung der Passion beiwohnen könnte. Er hat noch immer seine Scrupel über Klang u. Ausführbarkeit meiner Partitur. So setzte ihm z. B. Ehren-David den Floh ins Ohr, daß ich die Posaunen zu hoch führe, verschwieg aber dabei wohlweislich die heitere Thatsache, wie man in Leipzig nur mit 3 Tenorposaunen (!!!) zu wirthschaften pflege. - Die Differenzen mit Dresel lassen sich nicht gut ausgleichen, weil wir die letzten Ziele der Kunst mit gar zu verschiedenen Augen ansehen. Während ich mich nach Kräften bemühe, vom Einzelnen zum Ganzen vorzudringen, bleibt er durchschnittlich[?] in jenem stecken u. hält dieses für pure Illusion. Doch haben wir die Fehde über dergleichen Dinge suspendirt u. verkehren nur noch in rein musikalischen Fragen. Je mehr ich Dresel zu danken habe, umso fataler sind mir diese kleinen Zerwürfnisse, über die ich Sie übrigens dringend zu schweigen bitte. So wußte er neuerdings Sander zu bestimmen, den Allegro doch in Verlag zu nehmen, ein Entschluß, der mir eine Centnerlast von der Brust nimmt. Die Partitur wird im Laufe des Sommers gestochen u. soll, nebst Clavierauszug u. Stimmen zum nächsten Herbst ausgegeben werden. -

Wenn Sie Dresel in zwei Worten zur Aufführung der Passion einladen wollten, würden Sie mich sehr verbinden: dann kommt er sicherlich. Seine Adresse ist: Herren Otto Dresel in Leipzig (Hôtel zur Stadt Dresden). Auf alle Fälle zeigen Sie mir aber den Tag der Aufführung an - ich werde dann meinerseits bei Dresel nachhelfen. Wenn nur Ihre Blasinstrumente leidlich sind - das Uebrige findet sich schon. -
Doch nun leben Sie recht wohl u. seien Sie schönstens gegrüßt.
Ihr[?] Rob. Franz.
Halle d. 1.ten Febr. 71.

Brief vom 1. Februar 1871

2026-05-27T12:20:11Z

Admin: /* Brief von Robert Franz an Julius Schäffer, 1. Februar 1871 */

[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]
[[Kategorie:Quellen]]

== Brief von Robert Franz an Julius Schäffer, 1. Februar 1871 ==

Dieser Brief entstand zu einem für [[Robert Franz (1815-1892), deutscher Komponist]] schwierigen
Zeitpunkt: Seit 1867 beurlaubt, seit 1868 ohne alle Ämter,
zunehmend taub und finanziell bedrängt – und dennoch alles andere
als resigniert.

Adressat ist Julius Schäffer (1823–1902), Universitätsmusikdirektor
in Breslau, Schüler und enger Freund von Franz, der ihn in den
folgenden Jahren in der öffentlichen Auseinandersetzung um die
Bearbeitungsfrage tatkräftig verteidigte.

Der Brief zeigt Franz in unverstellter Deutlichkeit: Die
Formulierungen über Friedrich Chrysander lassen an Klarheit nichts
zu wünschen übrig.

Quelle: [https://st.museum-digital.de/object/1102
Stiftung Händel-Haus Halle, museum-digital Sachsen-Anhalt]

----

== Brieftext ==

Bester Schäffer!
In meinem letzten Briefe wollte ich mich nur bei Ihnen wieder einmal in Erinnerung bringen. Es versteht sich von selbst, daß Ihre Concerte keinen anderen Verlauf nehmen können, als ihn die Verhältnisse vorschreiben. Läßt sich aber gelegentlich eine Einlage im Interesse meiner Arbeiten bewerkstelligen, so wird es mir sehr lieb sein, wenn Sie an mich denken. -

Chrysanders Notizen über meine Publicationen haben mich, ich kann es nicht leugnen, in eine gelinde Wuth versetzt. Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne[?] gepachtet zu haben. Des Kerls Perfidie ist um so größer, als er mich vor einigen Jahren direkt zur Mitwirkung bei seinen "Denkmalen der Kunst" zu veranlassen suchte. Damals hatte ich bereits einen großen Haufen Bach'scher Werke bearbeitet u. Chrysander mußte doch wissen, was von mir zu erwarten stand. Aus mancherlei Gründen schlug ich den Antrag ab u. jetzt stellt sich der Bursche an, als versündigte ich mich geradezu an den alten Meistern. Wie sich ein honetter[?] Künstler dazu hergeben kann, sich von so einem ausrangirten Philologen in's Schlepptau nehmen zu lassen, ist schwer zu begreifen. Leider steht's aber mit der künstlerischen Respektabilität heut zu Tage schlecht genug, wie Sie das z. B. an den Brahms'schen Bearbeitungen der Kammerduette recht augenfällig wahrnehmen können. Um Dresel einen harmlosen Scherz zu bereiten, ging ich einige Stündchen auf die Quinten u. Octavenjagd - wie ich ein volles Schock (wörtlich zu nehmen) gespießt hatte, wurde mir die Geschichte doch gar zu langweilig u. ich klappte den Bettel[?] zu. Und mit solchem Schunde, der dem ersten besten Schuljungen Schande machen müßte, wagt es Herr Chrysander, seine Ausgaben aufzuputzen. Aber auch ganz abgesehen von der stinkenden Unsauberkeit des Tonsatzes, tragen diese Fabrikate den Stempel völliger Impotenz an der Stirn: nirgends ist ein Schimmer von Stimmung herausgedrückst[?] worden. Sollte mir unser Herr Redakteur etwa in die Quere kommen, dann reibe ich ihm, dem Mitverantwortlichen, jenes volle Schock meiner Flohjagd, dessen Spießung denn noch nicht ganz überflüssig war, derb unter die Nase. Angesichts solcher Erbärmlichkeiten wird aber eine Redensart wie: "wir könnten dem Manne dann helfen u. Freude bereiten" schlechterdings beleidigend. Der Esel hat ja nicht die geringste Vorstellung von dem eigentlichen Kernpunkte meiner Arbeiten. Diese werden hoffentlich dazu beitragen, den Leuten früher oder später über Händel'sche Art die Augen zu öffnen, während die öden Dudeleien jener Pfuscher nothwendig den Erfolg haben, des großen Mannes allgemeinere Anerkennung zu hintertreiben u. in weite Ferne hinauszuschieben. Besehe ich die Sache recht bei Lichte, so wird mir's immer klarer, daß Chrysander von dem coloss[a]len Ehrgeize besessen ist, mutterseelenallein die Rehabilitirung Händel's in's Werk setzen zu wollen. Offenbar genügen ihm die Triumphe auf dem Feld der Geschichte nicht mehr - er beabsichtigt auch "in Kunst" zu machen. Um seinen Schund aber an den Mann bringen zu können, muß er zuvor Besseres zu discreditiren suchen. Darum bleibt der Messias so lange aus, darum wurde in den Jahrbüchern für Musik der Schandartikel gegen Mendelssohn geschrieben, nur darum verdächtigt er jetzt heimlich meine Arbeiten. Auch Seb. Bach steht dem Kerl im Wege: die giftigen u. heimtückischen Angriffe zeigen es deutlich genug. Die Luft des 19.ten Jahrhunderts muß aber wahrlich von Elementen strotzen, die zur blinden Selbstanbetung nöthigen: es wäre sonst gar nicht zu begreifen, daß selbst die nüchternsten Gesellen diesem unseligen Cultus zur Beute fielen! -

Ob ich Ihnen schon von meinem kleinen Rencontre, das ich vorigen Herbst in Leipzig mit dem Herren v. Dommer hatte, vorplauderte, weiß ich nicht mehr recht. Der ist auch von einem possirlichen Dünkel angefressen[?], u. brütet fauchend auf seinen historischen Windeiern. Zu meinem gränzenlosen Erstaunen erfuhr ich da, daß es beim Accompagniment lediglich darauf ankäme, sich des Cembalo und der Orgel zu bedienen. Als ich dagegen in erster Linie einen stimmungsvollen u. reinen Tonsatz verlangte, schüttelte er lächelnd das Köpflein u. erklärte dergleichen für die größte Nebensache. In meiner Angst berief ich mich auf die vielen von mir angefertigten Clavierauszüge: man könne ja dieselben für Orgel u. Cembalo, wenn man überhaupt mit Bestimmtheit anzugeben wüsste, wo erstere u. wo letzeres einzutreten hätten, ausnutzen. Die wären wieder viel zu schwer gesetzt u. darum nicht im Geiste der alten Meister, orakelte der Mann. Kurzum, ich mochte es anfangen, wie ich wollte, er blieb selbstgefällig glucksend auf seinem Strohneste hocken. Endlich erbot er sich sogar, mir schriftlich ausführlicher Belehrung über meine Arbeiten zugehen lassen zu wollen. Auf meine Aeußerung hin, daß mir theoretische Belehrungen wenig nützen könnten, wenn sie nicht zugleich positive Berichtigungen des incriminirten Satzes brächten, erklärte er ganz naiv, dies nicht zu vermögen. Darauf ließ ich den trocknen Peter[?] stehen u. ging meiner Wege, überzeugt, einen neuen Widersacher gewonnen zu haben. Uebrigens erfuhr ich bei der Gelegenheit von Dommer, daß er zwar in Kunstdingen noch immer sehr mit Chrysander harmonire - Keineswegs aber in persönlichen. Er gab ihm die ehrenrührigsten Titulaturen, die ich hier gar nicht wiederholen mag. Sie werden also weise handeln, wenn Sie sich mit dem zweideutigen Patron nur so weit befassen, als unumgänglich nothwendig ist. -

Ueber die vier bis fünhundert kleinen Veränderungen, von denen Ihr Dr. Baumgart so verzückt in Chrysander's Zeitung redet, habe ich mich auch königlich amüsirt. Unsere Historiker nehmen überall die Miene an, als seien sie vom Schicksal ganz expreß[?] zu Anwalten der verfolgten Unschuld bestimmt. Gewöhnlich ist es aber eine verschobene Busenschleife oder eine gekrümmte Stecknadel, die sie dermaßen in Eifer bringt, daß sie über solche Lappalien die Hauptsache völlig aus den Augen verlieren. Der Herr v. Gugler wollte zum Don Juan vor allem Anderen einen guten deutschen Text liefern - der ist kläglich mißrathen u. somit hat er nur dazu beigetragen, die bereits herrschende Verwirrung über Mozart's Meisterwerk zu vermehren. Doch lassen wir diese Schulfuchser auf sich beruhen, wir werden sie doch nicht ändern!-

Sehr lieb wäre es mir, wenn Dresel Ihrer Aufführung der Passion beiwohnen könnte. Er hat noch immer seine Scrupel über Klang u. Ausführbarkeit meiner Partitur. So setzte ihm z. B. Ehren-David den Floh ins Ohr, daß ich die Posaunen zu hoch führe, verschwieg aber dabei wohlweislich die heitere Thatsache, wie man in Leipzig nur mit 3 Tenorposaunen (!!!) zu wirthschaften pflege. - Die Differenzen mit Dresel lassen sich nicht gut ausgleichen, weil wir die letzten Ziele der Kunst mit gar zu verschiedenen Augen ansehen. Während ich mich nach Kräften bemühe, vom Einzelnen zum Ganzen vorzudringen, bleibt er durchschnittlich[?] in jenem stecken u. hält dieses für pure Illusion. Doch haben wir die Fehde über dergleichen Dinge suspendirt u. verkehren nur noch in rein musikalischen Fragen. Je mehr ich Dresel zu danken habe, umso fataler sind mir diese kleinen Zerwürfnisse, über die ich Sie übrigens dringend zu schweigen bitte. So wußte er neuerdings Sander zu bestimmen, den Allegro doch in Verlag zu nehmen, ein Entschluß, der mir eine Centnerlast von der Brust nimmt. Die Partitur wird im Laufe des Sommers gestochen u. soll, nebst Clavierauszug u. Stimmen zum nächsten Herbst ausgegeben werden. -

Wenn Sie Dresel in zwei Worten zur Aufführung der Passion einladen wollten, würden Sie mich sehr verbinden: dann kommt er sicherlich. Seine Adresse ist: Herren Otto Dresel in Leipzig (Hôtel zur Stadt Dresden). Auf alle Fälle zeigen Sie mir aber den Tag der Aufführung an - ich werde dann meinerseits bei Dresel nachhelfen. Wenn nur Ihre Blasinstrumente leidlich sind - das Uebrige findet sich schon. -
Doch nun leben Sie recht wohl u. seien Sie schönstens gegrüßt.
Ihr[?] Rob. Franz.
Halle d. 1.ten Febr. 71.

Brief vom 1. Februar 1871

2026-05-27T12:18:38Z

Admin: /* Brief von Robert Franz an Julius Schäffer, 1. Februar 1871 */

[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]
[[Kategorie:Quellen]]

== Brief von Robert Franz an Julius Schäffer, 1. Februar 1871 ==

Dieser Brief entstand zu einem für [[Robert Franz]] schwierigen
Zeitpunkt: Seit 1867 beurlaubt, seit 1868 ohne alle Ämter,
zunehmend taub und finanziell bedrängt – und dennoch alles andere
als resigniert.

Adressat ist Julius Schäffer (1823–1902), Universitätsmusikdirektor
in Breslau, Schüler und enger Freund von Franz, der ihn in den
folgenden Jahren in der öffentlichen Auseinandersetzung um die
Bearbeitungsfrage tatkräftig verteidigte.

Der Brief zeigt Franz in unverstellter Deutlichkeit: Die
Formulierungen über Friedrich Chrysander lassen an Klarheit nichts
zu wünschen übrig.

Quelle: [https://st.museum-digital.de/object/1102
Stiftung Händel-Haus Halle, museum-digital Sachsen-Anhalt]

----

== Brieftext ==

Bester Schäffer!
In meinem letzten Briefe wollte ich mich nur bei Ihnen wieder einmal in Erinnerung bringen. Es versteht sich von selbst, daß Ihre Concerte keinen anderen Verlauf nehmen können, als ihn die Verhältnisse vorschreiben. Läßt sich aber gelegentlich eine Einlage im Interesse meiner Arbeiten bewerkstelligen, so wird es mir sehr lieb sein, wenn Sie an mich denken. -

Chrysanders Notizen über meine Publicationen haben mich, ich kann es nicht leugnen, in eine gelinde Wuth versetzt. Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne[?] gepachtet zu haben. Des Kerls Perfidie ist um so größer, als er mich vor einigen Jahren direkt zur Mitwirkung bei seinen "Denkmalen der Kunst" zu veranlassen suchte. Damals hatte ich bereits einen großen Haufen Bach'scher Werke bearbeitet u. Chrysander mußte doch wissen, was von mir zu erwarten stand. Aus mancherlei Gründen schlug ich den Antrag ab u. jetzt stellt sich der Bursche an, als versündigte ich mich geradezu an den alten Meistern. Wie sich ein honetter[?] Künstler dazu hergeben kann, sich von so einem ausrangirten Philologen in's Schlepptau nehmen zu lassen, ist schwer zu begreifen. Leider steht's aber mit der künstlerischen Respektabilität heut zu Tage schlecht genug, wie Sie das z. B. an den Brahms'schen Bearbeitungen der Kammerduette recht augenfällig wahrnehmen können. Um Dresel einen harmlosen Scherz zu bereiten, ging ich einige Stündchen auf die Quinten u. Octavenjagd - wie ich ein volles Schock (wörtlich zu nehmen) gespießt hatte, wurde mir die Geschichte doch gar zu langweilig u. ich klappte den Bettel[?] zu. Und mit solchem Schunde, der dem ersten besten Schuljungen Schande machen müßte, wagt es Herr Chrysander, seine Ausgaben aufzuputzen. Aber auch ganz abgesehen von der stinkenden Unsauberkeit des Tonsatzes, tragen diese Fabrikate den Stempel völliger Impotenz an der Stirn: nirgends ist ein Schimmer von Stimmung herausgedrückst[?] worden. Sollte mir unser Herr Redakteur etwa in die Quere kommen, dann reibe ich ihm, dem Mitverantwortlichen, jenes volle Schock meiner Flohjagd, dessen Spießung denn noch nicht ganz überflüssig war, derb unter die Nase. Angesichts solcher Erbärmlichkeiten wird aber eine Redensart wie: "wir könnten dem Manne dann helfen u. Freude bereiten" schlechterdings beleidigend. Der Esel hat ja nicht die geringste Vorstellung von dem eigentlichen Kernpunkte meiner Arbeiten. Diese werden hoffentlich dazu beitragen, den Leuten früher oder später über Händel'sche Art die Augen zu öffnen, während die öden Dudeleien jener Pfuscher nothwendig den Erfolg haben, des großen Mannes allgemeinere Anerkennung zu hintertreiben u. in weite Ferne hinauszuschieben. Besehe ich die Sache recht bei Lichte, so wird mir's immer klarer, daß Chrysander von dem coloss[a]len Ehrgeize besessen ist, mutterseelenallein die Rehabilitirung Händel's in's Werk setzen zu wollen. Offenbar genügen ihm die Triumphe auf dem Feld der Geschichte nicht mehr - er beabsichtigt auch "in Kunst" zu machen. Um seinen Schund aber an den Mann bringen zu können, muß er zuvor Besseres zu discreditiren suchen. Darum bleibt der Messias so lange aus, darum wurde in den Jahrbüchern für Musik der Schandartikel gegen Mendelssohn geschrieben, nur darum verdächtigt er jetzt heimlich meine Arbeiten. Auch Seb. Bach steht dem Kerl im Wege: die giftigen u. heimtückischen Angriffe zeigen es deutlich genug. Die Luft des 19.ten Jahrhunderts muß aber wahrlich von Elementen strotzen, die zur blinden Selbstanbetung nöthigen: es wäre sonst gar nicht zu begreifen, daß selbst die nüchternsten Gesellen diesem unseligen Cultus zur Beute fielen! -

Ob ich Ihnen schon von meinem kleinen Rencontre, das ich vorigen Herbst in Leipzig mit dem Herren v. Dommer hatte, vorplauderte, weiß ich nicht mehr recht. Der ist auch von einem possirlichen Dünkel angefressen[?], u. brütet fauchend auf seinen historischen Windeiern. Zu meinem gränzenlosen Erstaunen erfuhr ich da, daß es beim Accompagniment lediglich darauf ankäme, sich des Cembalo und der Orgel zu bedienen. Als ich dagegen in erster Linie einen stimmungsvollen u. reinen Tonsatz verlangte, schüttelte er lächelnd das Köpflein u. erklärte dergleichen für die größte Nebensache. In meiner Angst berief ich mich auf die vielen von mir angefertigten Clavierauszüge: man könne ja dieselben für Orgel u. Cembalo, wenn man überhaupt mit Bestimmtheit anzugeben wüsste, wo erstere u. wo letzeres einzutreten hätten, ausnutzen. Die wären wieder viel zu schwer gesetzt u. darum nicht im Geiste der alten Meister, orakelte der Mann. Kurzum, ich mochte es anfangen, wie ich wollte, er blieb selbstgefällig glucksend auf seinem Strohneste hocken. Endlich erbot er sich sogar, mir schriftlich ausführlicher Belehrung über meine Arbeiten zugehen lassen zu wollen. Auf meine Aeußerung hin, daß mir theoretische Belehrungen wenig nützen könnten, wenn sie nicht zugleich positive Berichtigungen des incriminirten Satzes brächten, erklärte er ganz naiv, dies nicht zu vermögen. Darauf ließ ich den trocknen Peter[?] stehen u. ging meiner Wege, überzeugt, einen neuen Widersacher gewonnen zu haben. Uebrigens erfuhr ich bei der Gelegenheit von Dommer, daß er zwar in Kunstdingen noch immer sehr mit Chrysander harmonire - Keineswegs aber in persönlichen. Er gab ihm die ehrenrührigsten Titulaturen, die ich hier gar nicht wiederholen mag. Sie werden also weise handeln, wenn Sie sich mit dem zweideutigen Patron nur so weit befassen, als unumgänglich nothwendig ist. -

Ueber die vier bis fünhundert kleinen Veränderungen, von denen Ihr Dr. Baumgart so verzückt in Chrysander's Zeitung redet, habe ich mich auch königlich amüsirt. Unsere Historiker nehmen überall die Miene an, als seien sie vom Schicksal ganz expreß[?] zu Anwalten der verfolgten Unschuld bestimmt. Gewöhnlich ist es aber eine verschobene Busenschleife oder eine gekrümmte Stecknadel, die sie dermaßen in Eifer bringt, daß sie über solche Lappalien die Hauptsache völlig aus den Augen verlieren. Der Herr v. Gugler wollte zum Don Juan vor allem Anderen einen guten deutschen Text liefern - der ist kläglich mißrathen u. somit hat er nur dazu beigetragen, die bereits herrschende Verwirrung über Mozart's Meisterwerk zu vermehren. Doch lassen wir diese Schulfuchser auf sich beruhen, wir werden sie doch nicht ändern!-

Sehr lieb wäre es mir, wenn Dresel Ihrer Aufführung der Passion beiwohnen könnte. Er hat noch immer seine Scrupel über Klang u. Ausführbarkeit meiner Partitur. So setzte ihm z. B. Ehren-David den Floh ins Ohr, daß ich die Posaunen zu hoch führe, verschwieg aber dabei wohlweislich die heitere Thatsache, wie man in Leipzig nur mit 3 Tenorposaunen (!!!) zu wirthschaften pflege. - Die Differenzen mit Dresel lassen sich nicht gut ausgleichen, weil wir die letzten Ziele der Kunst mit gar zu verschiedenen Augen ansehen. Während ich mich nach Kräften bemühe, vom Einzelnen zum Ganzen vorzudringen, bleibt er durchschnittlich[?] in jenem stecken u. hält dieses für pure Illusion. Doch haben wir die Fehde über dergleichen Dinge suspendirt u. verkehren nur noch in rein musikalischen Fragen. Je mehr ich Dresel zu danken habe, umso fataler sind mir diese kleinen Zerwürfnisse, über die ich Sie übrigens dringend zu schweigen bitte. So wußte er neuerdings Sander zu bestimmen, den Allegro doch in Verlag zu nehmen, ein Entschluß, der mir eine Centnerlast von der Brust nimmt. Die Partitur wird im Laufe des Sommers gestochen u. soll, nebst Clavierauszug u. Stimmen zum nächsten Herbst ausgegeben werden. -

Wenn Sie Dresel in zwei Worten zur Aufführung der Passion einladen wollten, würden Sie mich sehr verbinden: dann kommt er sicherlich. Seine Adresse ist: Herren Otto Dresel in Leipzig (Hôtel zur Stadt Dresden). Auf alle Fälle zeigen Sie mir aber den Tag der Aufführung an - ich werde dann meinerseits bei Dresel nachhelfen. Wenn nur Ihre Blasinstrumente leidlich sind - das Uebrige findet sich schon. -
Doch nun leben Sie recht wohl u. seien Sie schönstens gegrüßt.
Ihr[?] Rob. Franz.
Halle d. 1.ten Febr. 71.

Brief vom 1. Februar 1871

2026-05-27T12:17:38Z

Admin:

[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]
[[Kategorie:Quellen]]

== Brief von Robert Franz an Julius Schäffer, 1. Februar 1871 ==

Dieser Brief entstand zu einem für [[Robert Franz]] schwierigen
Zeitpunkt: Seit 1867 beurlaubt, seit 1868 ohne alle Ämter,
zunehmend taub und finanziell bedrängt – und dennoch alles andere
als resigniert.

Adressat ist Julius Schäffer (1823–1902), Universitätsmusikdirektor
in Breslau, Schüler und enger Freund von Franz, der ihn in den
folgenden Jahren in der öffentlichen Auseinandersetzung um die
Bearbeitungsfrage tatkräftig verteidigte.

Der Brief zeigt Franz in unverstellter Deutlichkeit: Die
Formulierungen über Friedrich Chrysander lassen an Klarheit nichts
zu wünschen übrig. Der Mann, der 280 – Verzeihung: über 350 –
stille, zarte Lieder schrieb, hatte durchaus Temperament.

Quelle: [https://st.museum-digital.de/object/1102
Stiftung Händel-Haus Halle, museum-digital Sachsen-Anhalt]

----
== Brieftext ==

Bester Schäffer!
In meinem letzten Briefe wollte ich mich nur bei Ihnen wieder einmal in Erinnerung bringen. Es versteht sich von selbst, daß Ihre Concerte keinen anderen Verlauf nehmen können, als ihn die Verhältnisse vorschreiben. Läßt sich aber gelegentlich eine Einlage im Interesse meiner Arbeiten bewerkstelligen, so wird es mir sehr lieb sein, wenn Sie an mich denken. -

Chrysanders Notizen über meine Publicationen haben mich, ich kann es nicht leugnen, in eine gelinde Wuth versetzt. Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne[?] gepachtet zu haben. Des Kerls Perfidie ist um so größer, als er mich vor einigen Jahren direkt zur Mitwirkung bei seinen "Denkmalen der Kunst" zu veranlassen suchte. Damals hatte ich bereits einen großen Haufen Bach'scher Werke bearbeitet u. Chrysander mußte doch wissen, was von mir zu erwarten stand. Aus mancherlei Gründen schlug ich den Antrag ab u. jetzt stellt sich der Bursche an, als versündigte ich mich geradezu an den alten Meistern. Wie sich ein honetter[?] Künstler dazu hergeben kann, sich von so einem ausrangirten Philologen in's Schlepptau nehmen zu lassen, ist schwer zu begreifen. Leider steht's aber mit der künstlerischen Respektabilität heut zu Tage schlecht genug, wie Sie das z. B. an den Brahms'schen Bearbeitungen der Kammerduette recht augenfällig wahrnehmen können. Um Dresel einen harmlosen Scherz zu bereiten, ging ich einige Stündchen auf die Quinten u. Octavenjagd - wie ich ein volles Schock (wörtlich zu nehmen) gespießt hatte, wurde mir die Geschichte doch gar zu langweilig u. ich klappte den Bettel[?] zu. Und mit solchem Schunde, der dem ersten besten Schuljungen Schande machen müßte, wagt es Herr Chrysander, seine Ausgaben aufzuputzen. Aber auch ganz abgesehen von der stinkenden Unsauberkeit des Tonsatzes, tragen diese Fabrikate den Stempel völliger Impotenz an der Stirn: nirgends ist ein Schimmer von Stimmung herausgedrückst[?] worden. Sollte mir unser Herr Redakteur etwa in die Quere kommen, dann reibe ich ihm, dem Mitverantwortlichen, jenes volle Schock meiner Flohjagd, dessen Spießung denn noch nicht ganz überflüssig war, derb unter die Nase. Angesichts solcher Erbärmlichkeiten wird aber eine Redensart wie: "wir könnten dem Manne dann helfen u. Freude bereiten" schlechterdings beleidigend. Der Esel hat ja nicht die geringste Vorstellung von dem eigentlichen Kernpunkte meiner Arbeiten. Diese werden hoffentlich dazu beitragen, den Leuten früher oder später über Händel'sche Art die Augen zu öffnen, während die öden Dudeleien jener Pfuscher nothwendig den Erfolg haben, des großen Mannes allgemeinere Anerkennung zu hintertreiben u. in weite Ferne hinauszuschieben. Besehe ich die Sache recht bei Lichte, so wird mir's immer klarer, daß Chrysander von dem coloss[a]len Ehrgeize besessen ist, mutterseelenallein die Rehabilitirung Händel's in's Werk setzen zu wollen. Offenbar genügen ihm die Triumphe auf dem Feld der Geschichte nicht mehr - er beabsichtigt auch "in Kunst" zu machen. Um seinen Schund aber an den Mann bringen zu können, muß er zuvor Besseres zu discreditiren suchen. Darum bleibt der Messias so lange aus, darum wurde in den Jahrbüchern für Musik der Schandartikel gegen Mendelssohn geschrieben, nur darum verdächtigt er jetzt heimlich meine Arbeiten. Auch Seb. Bach steht dem Kerl im Wege: die giftigen u. heimtückischen Angriffe zeigen es deutlich genug. Die Luft des 19.ten Jahrhunderts muß aber wahrlich von Elementen strotzen, die zur blinden Selbstanbetung nöthigen: es wäre sonst gar nicht zu begreifen, daß selbst die nüchternsten Gesellen diesem unseligen Cultus zur Beute fielen! -

Ob ich Ihnen schon von meinem kleinen Rencontre, das ich vorigen Herbst in Leipzig mit dem Herren v. Dommer hatte, vorplauderte, weiß ich nicht mehr recht. Der ist auch von einem possirlichen Dünkel angefressen[?], u. brütet fauchend auf seinen historischen Windeiern. Zu meinem gränzenlosen Erstaunen erfuhr ich da, daß es beim Accompagniment lediglich darauf ankäme, sich des Cembalo und der Orgel zu bedienen. Als ich dagegen in erster Linie einen stimmungsvollen u. reinen Tonsatz verlangte, schüttelte er lächelnd das Köpflein u. erklärte dergleichen für die größte Nebensache. In meiner Angst berief ich mich auf die vielen von mir angefertigten Clavierauszüge: man könne ja dieselben für Orgel u. Cembalo, wenn man überhaupt mit Bestimmtheit anzugeben wüsste, wo erstere u. wo letzeres einzutreten hätten, ausnutzen. Die wären wieder viel zu schwer gesetzt u. darum nicht im Geiste der alten Meister, orakelte der Mann. Kurzum, ich mochte es anfangen, wie ich wollte, er blieb selbstgefällig glucksend auf seinem Strohneste hocken. Endlich erbot er sich sogar, mir schriftlich ausführlicher Belehrung über meine Arbeiten zugehen lassen zu wollen. Auf meine Aeußerung hin, daß mir theoretische Belehrungen wenig nützen könnten, wenn sie nicht zugleich positive Berichtigungen des incriminirten Satzes brächten, erklärte er ganz naiv, dies nicht zu vermögen. Darauf ließ ich den trocknen Peter[?] stehen u. ging meiner Wege, überzeugt, einen neuen Widersacher gewonnen zu haben. Uebrigens erfuhr ich bei der Gelegenheit von Dommer, daß er zwar in Kunstdingen noch immer sehr mit Chrysander harmonire - Keineswegs aber in persönlichen. Er gab ihm die ehrenrührigsten Titulaturen, die ich hier gar nicht wiederholen mag. Sie werden also weise handeln, wenn Sie sich mit dem zweideutigen Patron nur so weit befassen, als unumgänglich nothwendig ist. -

Ueber die vier bis fünhundert kleinen Veränderungen, von denen Ihr Dr. Baumgart so verzückt in Chrysander's Zeitung redet, habe ich mich auch königlich amüsirt. Unsere Historiker nehmen überall die Miene an, als seien sie vom Schicksal ganz expreß[?] zu Anwalten der verfolgten Unschuld bestimmt. Gewöhnlich ist es aber eine verschobene Busenschleife oder eine gekrümmte Stecknadel, die sie dermaßen in Eifer bringt, daß sie über solche Lappalien die Hauptsache völlig aus den Augen verlieren. Der Herr v. Gugler wollte zum Don Juan vor allem Anderen einen guten deutschen Text liefern - der ist kläglich mißrathen u. somit hat er nur dazu beigetragen, die bereits herrschende Verwirrung über Mozart's Meisterwerk zu vermehren. Doch lassen wir diese Schulfuchser auf sich beruhen, wir werden sie doch nicht ändern!-

Sehr lieb wäre es mir, wenn Dresel Ihrer Aufführung der Passion beiwohnen könnte. Er hat noch immer seine Scrupel über Klang u. Ausführbarkeit meiner Partitur. So setzte ihm z. B. Ehren-David den Floh ins Ohr, daß ich die Posaunen zu hoch führe, verschwieg aber dabei wohlweislich die heitere Thatsache, wie man in Leipzig nur mit 3 Tenorposaunen (!!!) zu wirthschaften pflege. - Die Differenzen mit Dresel lassen sich nicht gut ausgleichen, weil wir die letzten Ziele der Kunst mit gar zu verschiedenen Augen ansehen. Während ich mich nach Kräften bemühe, vom Einzelnen zum Ganzen vorzudringen, bleibt er durchschnittlich[?] in jenem stecken u. hält dieses für pure Illusion. Doch haben wir die Fehde über dergleichen Dinge suspendirt u. verkehren nur noch in rein musikalischen Fragen. Je mehr ich Dresel zu danken habe, umso fataler sind mir diese kleinen Zerwürfnisse, über die ich Sie übrigens dringend zu schweigen bitte. So wußte er neuerdings Sander zu bestimmen, den Allegro doch in Verlag zu nehmen, ein Entschluß, der mir eine Centnerlast von der Brust nimmt. Die Partitur wird im Laufe des Sommers gestochen u. soll, nebst Clavierauszug u. Stimmen zum nächsten Herbst ausgegeben werden. -

Wenn Sie Dresel in zwei Worten zur Aufführung der Passion einladen wollten, würden Sie mich sehr verbinden: dann kommt er sicherlich. Seine Adresse ist: Herren Otto Dresel in Leipzig (Hôtel zur Stadt Dresden). Auf alle Fälle zeigen Sie mir aber den Tag der Aufführung an - ich werde dann meinerseits bei Dresel nachhelfen. Wenn nur Ihre Blasinstrumente leidlich sind - das Uebrige findet sich schon. -
Doch nun leben Sie recht wohl u. seien Sie schönstens gegrüßt.
Ihr[?] Rob. Franz.
Halle d. 1.ten Febr. 71.

Brief vom 1. Februar 1871

2026-05-27T12:16:37Z

Admin: Die Seite wurde neu angelegt: „Kategorie:Musik Kategorie:Musik/Persönlichkeiten Kategorie:Quellen == Brief von Robert Franz an Julius Schäffer, 1. Februar 1871 == Dieser Brief entstand zu einem für Robert Franz schwierigen Zeitpunkt: Seit 1867 beurlaubt, seit 1868 ohne alle Ämter, zunehmend taub und finanziell bedrängt – und dennoch alles andere als resigniert. Adressat ist Julius Schäffer (1823–1902), Universitätsmusikdirektor in Breslau, Schüler und…“

Robert Franz (1815-1892), deutscher Komponist

2026-05-27T12:15:29Z

Admin: /* Der Bearbeitungsstreit */

{{DISPLAYTITLE:Robert Franz}}
[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]

'''Robert Franz''' (eigentlich Robert Franz Julius Knauth; * 28. Juni 1815 in Halle an der Saale; † 24. Oktober 1892 ebenda) war ein deutscher Komponist, Organist und Dirigent. Er gilt als einer der bedeutendsten Liedkomponisten der deutschen Romantik – und gehört gleichzeitig zu den am stärksten vergessenen.

== Leben ==

=== Herkunft und Ausbildung ===

Robert Franz stammte aus einer alteingesessenen Hallorer-Familie. (Siehe auch: [[Halloren]]).
Er wuchs in Halle auf, wo er ab 1828 die Latina der Franckeschen Stiftungen besuchte. Früh fiel er durch musikalische Begabung auf; der dortige Kantor Carl Gottlob Abela ließ ihn die Proben des Schulchors am Klavier begleiten. Von 1835 bis 1837 studierte er Komposition bei Friedrich Schneider in Dessau und kehrte danach nach Halle zurück – in eine Stadt, die er zeit seines Lebens kaum verlassen sollte.

=== Berufliche Laufbahn in Halle ===

Nach schwierigen wirtschaftlichen Anfangsjahren übernahm Franz 1841 das Organistenamt an der Ulrichskirche. Im folgenden Jahr wurde er Dirigent der Singakademie Halle, die später seinen Namen annahm. 1848 heiratete er Marie Hinrichs, Tochter eines Professors und selbst Komponistin; das Paar hatte drei Kinder. 1859 wurde Franz schließlich zum Universitätsmusikdirektor ernannt – der Höhepunkt seiner öffentlichen Laufbahn.

=== Krankheit und Rückzug ===

Seit 1843 litt Franz an einem Nerven- und Ohrenleiden, das sich über Jahrzehnte progressiv verschlimmerte und schließlich zur vollständigen Taubheit führte. 1867 wurde er beurlaubt,
1868 musste er alle Ämter endgültig aufgeben. Die daraus folgende finanzielle Not war erheblich: Ein 1867 zuerkannter Ehrensold wurde ihm 1877 auf Betreiben von Widersachern wieder entzogen. Seinen Lebensunterhalt sicherte schließlich ein 1873 von Freunden und Kollegen – allen voran Franz Liszt – gestifteter Ehrenfonds in Höhe von 30.000 Talern.

Die letzten rund 25 Jahre seines Lebens verbrachte Franz in nahezu vollständiger Taubheit und sozialem Rückzug. Er starb am 24. Oktober 1892 in Halle.

1885 wurde ihm zu seinem 70. Geburtstag – anlässlich der Feier des 200. Geburtstags Georg Friedrich Händels – das Ehrenbürgerrecht der Stadt Halle verliehen.

== Das Werk ==

=== Die Lieder ===

Robert Franz schrieb über 350 Kunstlieder für Singstimme und Klavier – und fast ausschließlich das. Keine Symphonien, keine Opern, kein Streichquartett. Diese bewusste Konzentration auf eine einzige Gattung war seine Stärke und zugleich der Grund für sein späteres Vergessen.

Etwa ein Viertel seiner Lieder vertont Texte von Heinrich Heine. Daneben war Karl Wilhelm Osterwald ein bevorzugter Dichter. Franz' Vertonungsweise gilt als außerordentlich textgetreu und harmonisch differenziert – ohne Effekthascherei, in großer Zurückhaltung und mit feinem Klangsinn. Robert Schumann, dem Franz 1843 sein erstes gedrucktes Heft (op. 1, ''Zwölf Gesänge'') zuschickte, antwortete, die Lieder hätten ihm gefallen „wie seit langer Zeit keine mehr". Auch Mendelssohn, Liszt und Wagner äußerten sich anerkennend.

Zu den heute noch gelegentlich aufgeführten Liedern gehören:
* ''Aus meinen großen Schmerzen'', op. 5 Nr. 1 (Text: Heinrich Heine)
* ''Auf dem Meere'', op. 5 Nr. 3 (Text: Heinrich Heine)
* ''Sterne mit den goldnen Füßchen'' (Text: Heinrich Heine)
* ''Schilflieder'', op. 2 (Text: Nikolaus Lenau)

Die Opuszahlen von ''Sterne mit den goldnen Füßchen''
konnten nicht zweifelsfrei belegt werden.

=== Bearbeitungen von Bach und Händel ===

Neben seinen Liedern hat sich Franz einen – weniger bekannten, aber musikhistorisch bedeutsamen – Namen als Bearbeiter älterer Musik erworben. Als Leiter der Singakademie brachte er Werke von Johann Sebastian Bach und Georg Friedrich Händel zur Aufführung und fertigte dafür eigene Bearbeitungen an, die den Werken eine für das 19. Jahrhundert spielbare Gestalt gaben.

Zu seinen wichtigsten Bearbeitungen zählen:
* J. S. Bach: Matthäuspassion, Magnificat, Weihnachtsoratorium, Trauerode, zahlreiche Kantaten
* G. F. Händel: Messias, Jubilate, L'Allegro il Pensieroso ed il Moderato, Arien und Duette

Diese Bearbeitungen waren unter Musikern höchst umstritten – und führten zu einem der interessantesten musikwissenschaftlichen Streits der zweiten Hälfte des 19. Jahrhunderts (siehe unten).

== Der Bearbeitungsstreit ==

Franz' Ergänzungen des barocken Generalbasssatzes – also seine Ausführung der in Barockpartituren nur skizzenhaft notierten Begleitung – stießen auf scharfen Widerspruch der aufkommenden philologisch-historischen Schule. Besonders Friedrich Chrysander, Herausgeber der Händel-Gesamtausgabe, und Philipp Spitta, der maßgebliche Bach-Forscher der Zeit, kritisierten Franz' Herangehensweise als zu romantisierend und zu wenig historisch korrekt.

Franz seinerseits ließ sich das nicht gefallen. In einem [[Brief vom 1. Februar 1871]] an seinen Freund Julius Schäffer schrieb er über Chrysander:

: ''„Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne gepachtet zu haben."''

Der Streit wurde auch öffentlich geführt. Schäffer verfasste zwischen 1875 und 1880 eine Reihe von Streitschriften zur Verteidigung der Franz'schen Bearbeitungen, darunter ''Entgegnung auf Ph. Spitta's Artikel: Über das Accompagnement in den Kompositionen Seb. Bachs'' und ''Friedr. Chrysander in seinen Klavierauszügen zur deutschen Händel-Ausgabe''. Franz selbst meldete sich mit einem ''Offenen Brief an Eduard Hanslick'' und den ''Mitteilungen über J. S. Bachs Magnificat'' zu Wort.

Auf Seiten der Franz'schen Bearbeitungen standen namhafte Praktiker wie Liszt, Felix Mottl, Hans Richter und Arthur Nikisch. Die philologische Schule – Chrysander, Spitta – pochte auf Texttreue.

Dieser Streit ist im Kern derselbe, der bis heute nicht wirklich entschieden ist: Wie viel interpretatorische Freiheit darf – oder muss – eine lebendige Aufführung alter Musik haben? Franz stand auf der Seite der musikalischen Praxis; die Gegenseite bereitete den Boden für das vor, was später als Historisch Informierte Aufführungspraxis bekannt werden sollte.

== Warum ist Robert Franz vergessen? ==

Das ist eine berechtigte Frage – und die Antwort ist vielschichtig:

* '''Das Gattungsproblem:''' Franz schrieb fast ausschließlich Lieder. Im 20. Jahrhundert rückte das Kunstlied zunehmend an den Rand des Konzertlebens. Komponisten, die auch Symphonien, Kammermusik oder größere Vokalwerke hinterlassen haben – Brahms, Schumann, Schubert –, blieben im Repertoire präsent. Franz nicht.

* '''Kein zyklisches Hauptwerk:''' Anders als Schubert mit der ''Winterreise'' oder der ''Schönen Müllerin'' hinterließ Franz keinen Liederzyklus, der als geschlossenes Abendprogramm funktioniert und vermarktbar ist.

* '''Kein überregionales Netzwerk:''' Franz lebte und arbeitete sein Leben lang in Halle. Er hatte keine Schüler, die seine Tradition weitergetragen hätten, und keine Präsenz in den großen Musikzentren Wien, Leipzig oder Berlin.

* '''Die Taubheit:''' 25 Jahre Isolation am Ende seines Lebens bedeuteten: kein Spätwerk, keine Weiterentwicklung, keine späten Meisterwerke wie bei Beethoven oder Schubert.

Schumann hatte Franz übrigens bereits früh ermahnt, sich nicht auf das Lied zu beschränken. Franz blieb trotzdem bei seiner Wahl – konsequent und ohne Kompromisse. Das verdient Respekt, auch wenn es seinen Nachruhm gekostet hat.

== Zeitgenössische Wertschätzung ==

Dass Franz zu Lebzeiten keineswegs unbekannt war, zeigt eine Episode aus dem Jahr 1873: Als seine finanzielle Lage nach dem Verlust seiner Ämter und Bezüge prekär wurde, organisierten Franz Liszt und andere namhafte Musikerpersönlichkeiten einen Ehrenfonds, der Franz den Lebensunterhalt sicherte. Liszt hatte zudem bereits 1872 eine Monographie über Franz verfasst.

== Weblinks und Quellen ==

* [https://www.deutsche-biographie.de/sfz16975.html Deutsche Biographie – Robert Franz] (Allgemeine Deutsche Biographie, Band 48, 1904)
* [https://de.wikipedia.org/wiki/Robert_Franz Wikipedia – Robert Franz]
* [https://www.musikland-sachsenanhalt.de/beitraege/franz-robert-1815-1892/ Musikland Sachsen-Anhalt – Robert Franz]
* [https://halle.de/kultur-tourismus/stadtgeschichte/bekannte-persoenlichkeiten/beruehmte-hallenser/details/franz-robert Berühmte Hallenser – Stadt Halle]
* [https://st.museum-digital.de/object/1102 Brief von Robert Franz an Julius Schäffer, 1. Februar 1871] – Stiftung Händel-Haus Halle (museum-digital Sachsen-Anhalt)
* [https://www.klassik-heute.com/4daction/www_komponist?id=43036&bio= Klassik Heute – Biographie Robert Franz]

----
''Seite erstellt im Kontext eines Konzertprogramms mit Liedern von Robert Franz, Mai 2026.''

Robert Franz (1815-1892), deutscher Komponist

2026-05-27T12:05:58Z

Admin: /* Herkunft und Ausbildung */

{{DISPLAYTITLE:Robert Franz}}
[[Kategorie:Musik]]
[[Kategorie:Musik/Persönlichkeiten]]

'''Robert Franz''' (eigentlich Robert Franz Julius Knauth; * 28. Juni 1815 in Halle an der Saale; † 24. Oktober 1892 ebenda) war ein deutscher Komponist, Organist und Dirigent. Er gilt als einer der bedeutendsten Liedkomponisten der deutschen Romantik – und gehört gleichzeitig zu den am stärksten vergessenen.

== Leben ==

=== Herkunft und Ausbildung ===

Robert Franz stammte aus einer alteingesessenen Hallorer-Familie. (Siehe auch: [[Halloren]]).
Er wuchs in Halle auf, wo er ab 1828 die Latina der Franckeschen Stiftungen besuchte. Früh fiel er durch musikalische Begabung auf; der dortige Kantor Carl Gottlob Abela ließ ihn die Proben des Schulchors am Klavier begleiten. Von 1835 bis 1837 studierte er Komposition bei Friedrich Schneider in Dessau und kehrte danach nach Halle zurück – in eine Stadt, die er zeit seines Lebens kaum verlassen sollte.

=== Berufliche Laufbahn in Halle ===

Nach schwierigen wirtschaftlichen Anfangsjahren übernahm Franz 1841 das Organistenamt an der Ulrichskirche. Im folgenden Jahr wurde er Dirigent der Singakademie Halle, die später seinen Namen annahm. 1848 heiratete er Marie Hinrichs, Tochter eines Professors und selbst Komponistin; das Paar hatte drei Kinder. 1859 wurde Franz schließlich zum Universitätsmusikdirektor ernannt – der Höhepunkt seiner öffentlichen Laufbahn.

=== Krankheit und Rückzug ===

Seit 1843 litt Franz an einem Nerven- und Ohrenleiden, das sich über Jahrzehnte progressiv verschlimmerte und schließlich zur vollständigen Taubheit führte. 1867 wurde er beurlaubt,
1868 musste er alle Ämter endgültig aufgeben. Die daraus folgende finanzielle Not war erheblich: Ein 1867 zuerkannter Ehrensold wurde ihm 1877 auf Betreiben von Widersachern wieder entzogen. Seinen Lebensunterhalt sicherte schließlich ein 1873 von Freunden und Kollegen – allen voran Franz Liszt – gestifteter Ehrenfonds in Höhe von 30.000 Talern.

Die letzten rund 25 Jahre seines Lebens verbrachte Franz in nahezu vollständiger Taubheit und sozialem Rückzug. Er starb am 24. Oktober 1892 in Halle.

1885 wurde ihm zu seinem 70. Geburtstag – anlässlich der Feier des 200. Geburtstags Georg Friedrich Händels – das Ehrenbürgerrecht der Stadt Halle verliehen.

== Das Werk ==

=== Die Lieder ===

Robert Franz schrieb über 350 Kunstlieder für Singstimme und Klavier – und fast ausschließlich das. Keine Symphonien, keine Opern, kein Streichquartett. Diese bewusste Konzentration auf eine einzige Gattung war seine Stärke und zugleich der Grund für sein späteres Vergessen.

Etwa ein Viertel seiner Lieder vertont Texte von Heinrich Heine. Daneben war Karl Wilhelm Osterwald ein bevorzugter Dichter. Franz' Vertonungsweise gilt als außerordentlich textgetreu und harmonisch differenziert – ohne Effekthascherei, in großer Zurückhaltung und mit feinem Klangsinn. Robert Schumann, dem Franz 1843 sein erstes gedrucktes Heft (op. 1, ''Zwölf Gesänge'') zuschickte, antwortete, die Lieder hätten ihm gefallen „wie seit langer Zeit keine mehr". Auch Mendelssohn, Liszt und Wagner äußerten sich anerkennend.

Zu den heute noch gelegentlich aufgeführten Liedern gehören:
* ''Aus meinen großen Schmerzen'', op. 5 Nr. 1 (Text: Heinrich Heine)
* ''Auf dem Meere'', op. 5 Nr. 3 (Text: Heinrich Heine)
* ''Sterne mit den goldnen Füßchen'' (Text: Heinrich Heine)
* ''Schilflieder'', op. 2 (Text: Nikolaus Lenau)

Die Opuszahlen von ''Sterne mit den goldnen Füßchen''
konnten nicht zweifelsfrei belegt werden.

=== Bearbeitungen von Bach und Händel ===

Neben seinen Liedern hat sich Franz einen – weniger bekannten, aber musikhistorisch bedeutsamen – Namen als Bearbeiter älterer Musik erworben. Als Leiter der Singakademie brachte er Werke von Johann Sebastian Bach und Georg Friedrich Händel zur Aufführung und fertigte dafür eigene Bearbeitungen an, die den Werken eine für das 19. Jahrhundert spielbare Gestalt gaben.

Zu seinen wichtigsten Bearbeitungen zählen:
* J. S. Bach: Matthäuspassion, Magnificat, Weihnachtsoratorium, Trauerode, zahlreiche Kantaten
* G. F. Händel: Messias, Jubilate, L'Allegro il Pensieroso ed il Moderato, Arien und Duette

Diese Bearbeitungen waren unter Musikern höchst umstritten – und führten zu einem der interessantesten musikwissenschaftlichen Streits der zweiten Hälfte des 19. Jahrhunderts (siehe unten).

== Der Bearbeitungsstreit ==

Franz' Ergänzungen des barocken Generalbasssatzes – also seine Ausführung der in Barockpartituren nur skizzenhaft notierten Begleitung – stießen auf scharfen Widerspruch der aufkommenden philologisch-historischen Schule. Besonders Friedrich Chrysander, Herausgeber der Händel-Gesamtausgabe, und Philipp Spitta, der maßgebliche Bach-Forscher der Zeit, kritisierten Franz' Herangehensweise als zu romantisierend und zu wenig historisch korrekt.

Franz seinerseits ließ sich das nicht gefallen. In einem Brief vom 1. Februar 1871 an seinen Freund Julius Schäffer schrieb er über Chrysander:

: ''„Das ist ja ein ganz unverschämter Schlingel, der sich ernsthaft einzubilden scheint, Händel, weil er sich sonst einiges Verdienst um ihn erworben hat, ausschließlich als Domäne gepachtet zu haben."''

Der Streit wurde auch öffentlich geführt. Schäffer verfasste zwischen 1875 und 1880 eine Reihe von Streitschriften zur Verteidigung der Franz'schen Bearbeitungen, darunter ''Entgegnung auf Ph. Spitta's Artikel: Über das Accompagnement in den Kompositionen Seb. Bachs'' und ''Friedr. Chrysander in seinen Klavierauszügen zur deutschen Händel-Ausgabe''. Franz selbst meldete sich mit einem ''Offenen Brief an Eduard Hanslick'' und den ''Mitteilungen über J. S. Bachs Magnificat'' zu Wort.

Auf Seiten der Franz'schen Bearbeitungen standen namhafte Praktiker wie Liszt, Felix Mottl, Hans Richter und Arthur Nikisch. Die philologische Schule – Chrysander, Spitta – pochte auf Texttreue.

Dieser Streit ist im Kern derselbe, der bis heute nicht wirklich entschieden ist: Wie viel interpretatorische Freiheit darf – oder muss – eine lebendige Aufführung alter Musik haben? Franz stand auf der Seite der musikalischen Praxis; die Gegenseite bereitete den Boden für das vor, was später als Historisch Informierte Aufführungspraxis bekannt werden sollte.

== Warum ist Robert Franz vergessen? ==

Das ist eine berechtigte Frage – und die Antwort ist vielschichtig:

* '''Das Gattungsproblem:''' Franz schrieb fast ausschließlich Lieder. Im 20. Jahrhundert rückte das Kunstlied zunehmend an den Rand des Konzertlebens. Komponisten, die auch Symphonien, Kammermusik oder größere Vokalwerke hinterlassen haben – Brahms, Schumann, Schubert –, blieben im Repertoire präsent. Franz nicht.

* '''Kein zyklisches Hauptwerk:''' Anders als Schubert mit der ''Winterreise'' oder der ''Schönen Müllerin'' hinterließ Franz keinen Liederzyklus, der als geschlossenes Abendprogramm funktioniert und vermarktbar ist.

* '''Kein überregionales Netzwerk:''' Franz lebte und arbeitete sein Leben lang in Halle. Er hatte keine Schüler, die seine Tradition weitergetragen hätten, und keine Präsenz in den großen Musikzentren Wien, Leipzig oder Berlin.

* '''Die Taubheit:''' 25 Jahre Isolation am Ende seines Lebens bedeuteten: kein Spätwerk, keine Weiterentwicklung, keine späten Meisterwerke wie bei Beethoven oder Schubert.

Schumann hatte Franz übrigens bereits früh ermahnt, sich nicht auf das Lied zu beschränken. Franz blieb trotzdem bei seiner Wahl – konsequent und ohne Kompromisse. Das verdient Respekt, auch wenn es seinen Nachruhm gekostet hat.

== Zeitgenössische Wertschätzung ==

Dass Franz zu Lebzeiten keineswegs unbekannt war, zeigt eine Episode aus dem Jahr 1873: Als seine finanzielle Lage nach dem Verlust seiner Ämter und Bezüge prekär wurde, organisierten Franz Liszt und andere namhafte Musikerpersönlichkeiten einen Ehrenfonds, der Franz den Lebensunterhalt sicherte. Liszt hatte zudem bereits 1872 eine Monographie über Franz verfasst.

== Weblinks und Quellen ==

* [https://www.deutsche-biographie.de/sfz16975.html Deutsche Biographie – Robert Franz] (Allgemeine Deutsche Biographie, Band 48, 1904)
* [https://de.wikipedia.org/wiki/Robert_Franz Wikipedia – Robert Franz]
* [https://www.musikland-sachsenanhalt.de/beitraege/franz-robert-1815-1892/ Musikland Sachsen-Anhalt – Robert Franz]
* [https://halle.de/kultur-tourismus/stadtgeschichte/bekannte-persoenlichkeiten/beruehmte-hallenser/details/franz-robert Berühmte Hallenser – Stadt Halle]
* [https://st.museum-digital.de/object/1102 Brief von Robert Franz an Julius Schäffer, 1. Februar 1871] – Stiftung Händel-Haus Halle (museum-digital Sachsen-Anhalt)
* [https://www.klassik-heute.com/4daction/www_komponist?id=43036&bio= Klassik Heute – Biographie Robert Franz]

----
''Seite erstellt im Kontext eines Konzertprogramms mit Liedern von Robert Franz, Mai 2026.''

Halloren

2026-05-27T12:05:19Z

Admin:

[[Kategorie:Halle (Saale)]]

Als '''Halloren''' werden seit dem Spätmittelalter die Salinenarbeiter in Halle an der Saale bezeichnet – genauer: die Mitglieder der '''Salzwirker-Brüderschaft im Thale zu Halle''', die die natürlich austretende Sole der Stadt in Herdpfannen zu Salz verkochten. Die Brüderschaft wurde 1491 gegründet und existiert bis heute; sie ist eine Besonderheit, die es ausschließlich in Halle gibt.

Umgangssprachlich bezeichnet "Hallore" auch einen alteingesessenen Hallenser, dessen Familie seit Generationen in der Stadt verwurzelt ist.

Die [[wikipedia:de:Halloren|Halloren]] – ausführlicher Artikel in der deutschsprachigen Wikipedia.

----
''Erstellt als Hintergrundseite zur Biographie [[Robert Franz (1815-1892), deutscher Komponist]].''

Halloren

2026-05-27T12:02:49Z

Admin: Die Seite wurde neu angelegt: „Kategorie:Halle (Saale) Als '''Halloren''' werden seit dem Spätmittelalter die Salinenarbeiter in Halle an der Saale bezeichnet – genauer: die Mitglieder der '''Salzwirker-Brüderschaft im Thale zu Halle''', die die natürlich austretende Sole der Stadt in Herdpfannen zu Salz verkochten. Die Brüderschaft wurde 1491 gegründet und existiert bis heute; sie ist eine Besonderheit, die es ausschließlich in Halle gibt. Umgangssprachlich bezeichnet "H…“