Projektübersicht

Ein klassischer Heimrouter wurde durch eine virtualisierte OPNsense-Firewall auf einem Proxmox VE Hypervisor ersetzt. Die Firewall übernimmt PPPoE-Einwahl beim ISP, DHCP, verschlüsseltes DNS, granulare Firewall-Regeln und VPN-Gateway. Dazu wurde das Netzwerk in physisch getrennte Segmente aufgeteilt.

1. Situation (Ausgangslage)

Das Heimnetzwerk lief über einen handelsüblichen Consumer-Router. Alle Geräte befanden sich im selben Subnetz, ohne Segmentierung und ohne Kontrolle über DNS-Anfragen. DNS lief im Klartext zum ISP, jede aufgerufene Domain war für den Anbieter sichtbar. Firewall-Regeln beschränkten sich auf NAT und einfache Portfreigaben. Es gab keine Möglichkeit, ein NAS mit sensiblen Daten vom restlichen Netzwerk zu isolieren, keinen zentralen VPN-Zugang und keine Blocklisten gegen Tracking oder Malware.

2. Task (Zielsetzung)

• Vollständiger Router-Ersatz: Der Consumer-Router soll durch eine professionelle Firewall ersetzt werden, die direkt per PPPoE beim Glasfaser-ISP einwählt.
• Netzwerksegmentierung: Mindestens zwei getrennte Segmente: LAN für Arbeitsgeräte und ein isoliertes Segment für das NAS mit Familiendaten.
• DNS-Verschlüsselung: Alle DNS-Anfragen im Netzwerk sollen per TLS verschlüsselt werden. Geräte dürfen die zentrale DNS-Auflösung nicht umgehen können.
• VPN-Gateway: Ein WireGuard-Tunnel soll den gesamten Internetverkehr über einen externen VPN-Anbieter leiten.

3. Action (Umsetzung)

A. OPNsense als VM auf Proxmox

OPNsense wurde als KVM-VM auf dem vorhandenen Proxmox VE Hypervisor eingerichtet. Die VM erhielt drei virtuelle Netzwerkkarten (VirtIO), jeweils an eine eigene Proxmox-Bridge gebunden. Jede Bridge ist mit einem eigenen physischen Ethernet-Port verbunden. Das ergibt physische Segmentierung statt reiner VLAN-Trennung auf einer einzelnen Leitung.

Der CPU-Typ wurde auf "host" gesetzt, damit alle AES-NI Instruktionen für VPN-Verschlüsselung direkt verfügbar sind. Als BIOS kam OVMF (UEFI) zum Einsatz, da OPNsense (FreeBSD-basiert) damit stabiler bootet. Über die Autostart-Konfiguration in Proxmox startet die Firewall-VM als erstes System beim Boot, noch vor allen anderen VMs und Containern.

B. PPPoE-Einwahl mit VLAN-Tagging

Deutsche Glasfaser-Anbieter erfordern VLAN-Tagging (ID 7) auf dem WAN-Interface. Ein klassischer Heimrouter erledigt das im Hintergrund. Bei OPNsense muss zuerst ein VLAN-Interface (802.1q) auf dem WAN-Port angelegt werden. Darauf läuft dann die PPPoE-Einwahl mit den ISP-Zugangsdaten. Die MTU wurde auf 1492 Bytes gesetzt (Ethernet 1500 minus 8 Bytes PPPoE-Header), MSS-Clamping verhindert fragmentierte Pakete.

C. Netzwerksegmentierung

Das Netzwerk wurde in zwei physisch getrennte Segmente aufgeteilt:

Das LAN-Segment für alle Arbeitsgeräte, VMs und Container. Hier laufen der Hypervisor, ein Backup-Server, ein Monitoring-Stack, ein Git-Server, ein Fileserver und eine Portfolio-Website. Alle bekommen ihre IP per DHCP-Reservierung (Kea DHCP) und nutzen OPNsense als DNS-Server und Gateway.

Das NAS-Segment für die Synology NAS mit Familiendaten. Der Zugriff ist per Firewall-Regel auf genau ein System beschränkt: nur der Backup-Server darf per NFS auf die NAS zugreifen, und auch nur auf einen dedizierten Backup-Ordner. Kein anderes Gerät im LAN kann die NAS direkt erreichen.

Ein drittes, rein virtuelles Segment (ohne physischen Port) wurde für ein geplantes Hacking Lab vorbereitet.

D. DNS-Verschlüsselung und Bypass-Schutz

Unbound-DNS wurde als lokaler DNS-Resolver konfiguriert. Alle DNS-Anfragen werden per DNS-over-TLS (Port 853) an Quad9 weitergeleitet. Die Zertifikatsverifizierung (Verify CN) ist aktiv, DNSSEC validiert die Antworten zusätzlich gegen Manipulation. Die Option "Forward first" ist bewusst deaktiviert: wenn Quad9 nicht erreichbar ist, fällt DNS komplett aus statt unbemerkt auf unverschlüsseltes DNS zurückzufallen.

Eine Firewall-Regel an Position 1 im LAN blockiert alle DNS-Anfragen (Port 53) die nicht an OPNsense gerichtet sind. Das verhindert, dass Smart-TVs, IoT-Geräte oder Apps mit fest einprogrammierten DNS-Servern die Verschlüsselung und Blocklisten umgehen.

Ergänzend wurden mehrere Blocklisten (hagezi Multi PRO, Threat Intelligence, Fake/Scams) aktiviert, die täglich per Cron-Job automatisch aktualisiert werden.

E. WireGuard VPN-Gateway

Ein WireGuard-Tunnel zu einem externen VPN-Anbieter wurde eingerichtet. Das WireGuard-Interface wurde als eigenes OPNsense-Interface mit dediziertem Gateway angelegt. Eine Firewall-Regel im LAN erzwingt, dass der gesamte Internetverkehr über diesen Tunnel läuft (Strict Mode): kein VPN, kein Internet. Die Konfiguration ist vorbereitet für Split-Tunneling per Policy-Based Routing, damit bestimmte Dienste den Tunnel umgehen können.

4. Result (Ergebnis & Verifikation)

Der Consumer-Router wurde vollständig abgelöst. Die PPPoE-Verbindung zum ISP steht stabil, die Firewall läuft seit der Einrichtung ohne ungeplante Ausfälle.

DNS-Verschlüsselung wurde per tcpdump auf dem WAN-Interface verifiziert: ausschliesslich Traffic auf Port 853 (TLS), kein Port 53 (Klartext) sichtbar. Ein DNS-Leak-Test (dnsleaktest.com) bestätigt, dass nur Quad9-Server antworten, keine ISP-eigenen DNS-Server. Der DNS-Bypass-Schutz wurde getestet, indem direkt ein externer DNS-Server angefragt wurde: Verbindung wird korrekt blockiert.

Die Netzwerksegmentierung funktioniert wie geplant. Aus dem LAN ist die NAS nicht erreichbar, nur der autorisierte Backup-Server hat Zugriff. Die Backup-Daten landen verschlüsselt auf einem isolierten NFS-Share.

Alle Dienste im LAN (Monitoring, Git, Webserver, Fileserver) beziehen DNS, DHCP und NTP zentral von OPNsense und starten nach einem Reboot in der korrekten Reihenfolge automatisch.

Lessons Learned

• VLAN-Tagging ist bei deutschen Glasfaser-Anbietern Pflicht. VLAN 7 auf dem WAN-Interface war nötig damit die PPPoE-Einwahl funktioniert. Eine Fritzbox macht das intern und unsichtbar. Wer den Router selbst baut, muss das wissen.
• DNS-Bypass-Schutz ist keine Kür, sondern Pflicht. Viele Geräte haben fest einprogrammierte DNS-Server und umgehen den lokalen Resolver komplett. Ohne die Blockier-Regel auf Position 1 wären DoT und Blocklisten wirkungslos für diese Geräte.
• "Lieber Ausfall als Leak" ist eine bewusste Designentscheidung. Forward-first klingt nach sinnvollem Fallback, ist aber eine Sicherheitslücke: bei Ausfall des verschlüsselten DNS-Servers fällt das System auf Klartext-DNS zurück, ohne dass der Nutzer es merkt.
• Physische Segmentierung ist einfacher und sicherer als VLANs. Separate NICs an separaten Bridges eliminieren das Risiko von VLAN-Hopping. Bei ausreichend Hardware-Ports ist das der direktere Weg.
• OPNsense speichert alles in einer einzigen XML-Datei. Passwörter, Private Keys und Zertifikate liegen in der config.xml. Diese Datei nie ungefiltert exportieren oder teilen.