pfSense in der Praxis – vom ersten Boot zum segmentierten Netz

Praxisleitfaden für pfSense CE/Plus – Planung, Installation auf Hardware oder Proxmox, VLANs, Aliase, Regeln, NAT, DNS, WireGuard, pfBlockerNG, Suricata, Backups, Hochverfügbarkeit und Fehlersuche.

pfSense in der Praxis

pfSense ist die wohl bekannteste Open-Source-Firewall. Sie läuft auf fast jeder x86-Hardware, als VM oder auf den Appliances von Netgate und ist im Homelab genauso zu Hause wie in kleinen und mittleren Unternehmen. Dieser Leitfaden ist bewusst praktisch aufgebaut: Er führt Schritt für Schritt von der Planung bis zu einem segmentierten Netz mit VPN, DNS-Filter und Angriffserkennung.


pfSense auf einen Blick

pfSense CE pfSense Plus
Für wen Homelab, Lernen, kleine Netze Unternehmen, Netgate-Hardware, AWS/Azure
Kosten kostenlos (Apache-2.0-Lizenz) auf Netgate-Hardware enthalten, sonst Abo
Release-Rhythmus seltener, größere Sprünge (2.7 → 2.8) regelmäßig, Versionsschema JJ.MM
Support Community-Forum Netgate TAC, 24/7 gegen Gebühr
Mehrere Firewalls zentral verwalten – Netgate Nexus

Was pfSense ab Werk kann: Stateful Firewall, NAT, Multi-WAN, VLANs, IPsec und OpenVPN, DHCP (Kea), DNS-Resolver (Unbound), Traffic Shaping, Captive Portal, Hochverfügbarkeit (CARP). Über Pakete kommt dazu: WireGuard, pfBlockerNG, Suricata/Snort, HAProxy, ACME (Let’s Encrypt), FRR (BGP/OSPF) und vieles mehr.


1. Planung: erst Papier, dann Klicks

Netzplan

Bevor du pfSense installierst, lege fest, welche Netze es geben soll. Ein bewährtes Schema für ein Homelab:

VLAN Name Netz Gateway (pfSense) Zweck
– WAN vom Provider – Internet
10 LAN 10.10.10.0/24 10.10.10.1 Arbeitsrechner, Notebooks
20 SERVER 10.10.20.0/24 10.10.20.1 NAS, Proxmox-VMs, Dienste
30 IOT 10.10.30.0/24 10.10.30.1 Smart Home, TV, Drucker
40 GAESTE 10.10.40.0/24 10.10.40.1 Gäste-WLAN
99 MGMT 10.10.99.0/24 10.10.99.1 Switches, Access Points, Hypervisor

Hardware dimensionieren

Netgate nennt als Mindestanforderung: 64-Bit-x86-CPU, 1 GB RAM, 8 GB Speicher und mindestens eine kompatible Netzwerkkarte. Für den echten Betrieb gilt:

Einsatz Empfehlung (Erfahrungswerte)
Reiner Router/Firewall bis 1 Gbit/s aktuelle 2–4-Kern-CPU, 4 GB RAM, SSD
Mit VPN (WireGuard/IPsec) CPU mit AES-NI; VPN-Durchsatz hängt fast nur an der CPU
Mit Suricata/Snort und pfBlockerNG 8 GB RAM oder mehr, schnelle SSD – IDS/IPS und große Blocklisten brauchen viel Speicher
Mehrere Gbit/s starke Einzelkernleistung, Intel-NICs, ggf. 10-GbE-SFP+

2. Installation

Variante A: eigene Hardware

  1. Installer bei Netgate herunterladen und auf einen USB-Stick schreiben.
  2. Vom Stick booten und dem Installer folgen. Der aktuelle Netgate Installer benötigt während der Installation eine Internetverbindung.
  3. Als Dateisystem ZFS wählen – robuster bei Stromausfällen und mit Boot-Umgebungen für Updates.
  4. Nach dem Neustart erscheint das Konsolenmenü.

Variante B: als VM auf Proxmox VE

Sehr beliebt im Homelab – pfSense läuft dann neben den anderen VMs auf demselben Host.

Vorbereitung auf dem Host:

Bridge Physischer Port Aufgabe
vmbr0 NIC zum Provider-Modem WAN von pfSense
vmbr1 NIC zum Switch (VLAN-aware) LAN + alle VLANs als Trunk

VM anlegen:

  • Gastsystem Other, BIOS OVMF (UEFI), Maschinentyp q35
  • 2–4 vCPUs (Typ host), 4–8 GB RAM, 32 GB Festplatte (VirtIO SCSI)
  • Netzwerkkarten als VirtIO: net0 an vmbr0, net1 an vmbr1
  • Zusätzlich eine serielle Schnittstelle hinzufügen – laut Netgate startet pfSense per EFI auf Proxmox damit zuverlässiger, auch wenn sie nicht benutzt wird
  • Optional: PCI-Passthrough einer echten NIC für das WAN (bestes Verhalten, z. B. bei PPPoE)

Nach der Installation unbedingt:

text
System → Advanced → Networking
  [x] Disable hardware checksum offload
  Save → Diagnostics → Reboot

3. Erster Start und Grundeinrichtung

Konsolenmenü

Nach dem Boot zeigt pfSense ein Textmenü. Die wichtigsten Punkte:

Option Wofür
1 Assign Interfaces WAN/LAN den Netzwerkkarten zuordnen, VLANs anlegen
2 Set interface(s) IP address LAN-Adresse ändern, DHCP an/aus – Rettung bei Fehlkonfiguration
3 Reset webConfigurator password Admin-Passwort zurücksetzen
4 Reset to factory defaults Werkseinstellungen
8 Shell Kommandozeile für Diagnose

Setup-Assistent in der Weboberfläche

  1. PC an das LAN anschließen → https://192.168.1.1 → Login admin / pfsense.
  2. Hostname und Domain festlegen (z. B. fw01 / home.arpa).
  3. DNS-Server können leer bleiben – pfSense arbeitet standardmäßig als eigener Resolver.
  4. Zeitzone Europe/Berlin.
  5. WAN-Typ wählen: DHCP (hinter einem Router), PPPoE (Glasfaser/DSL direkt) oder Static.
  6. LAN-Adresse laut Netzplan setzen, z. B. 10.10.10.1/24.
  7. Admin-Passwort ändern und abschließen.

Sofort danach erledigen:

  • System → User Manager: eigenen Admin-Benutzer anlegen, admin nicht mehr verwenden
  • System → Advanced → Admin Access: nur HTTPS, eigener Port optional, SSH nur mit Schlüssel (oder aus)
  • System → Update: auf aktuelle Version bringen
  • System → Advanced → Networking: IPv6 bewusst aktivieren oder deaktivieren

4. VLANs anlegen

Der Switch-Port zur Firewall wird als Trunk konfiguriert (alle VLANs tagged). In pfSense:

  1. Interfaces → Assignments → VLANs → Add: Parent-Interface (die LAN-NIC), VLAN Tag (z. B. 20), Beschreibung SERVER.
  2. Interfaces → Assignments: das neue VLAN in der Liste Available network ports hinzufügen.
  3. Das neue Interface (z. B. OPT1) öffnen:
    • Enable anhaken
    • Beschreibung: SERVER
    • IPv4: Static – 10.10.20.1/24
  4. Services → DHCP Server → SERVER: DHCP aktivieren, Bereich z. B. 10.10.20.100 – 10.10.20.199.

5. Aliase: das Werkzeug für lesbare Regeln

Aliase fassen Adressen, Netze oder Ports unter einem Namen zusammen (Firewall → Aliases). Regeln werden damit kürzer, verständlicher und leichter zu pflegen.

Alias Typ Inhalt Verwendung
RFC1918 Network(s) 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 „alle internen Netze“
ADMIN_HOSTS Host(s) 10.10.10.50, 10.10.10.51 Admin-Rechner
NAS Host(s) 10.10.20.10 Ziel für Dateifreigaben
PORTS_WEB Port(s) 80, 443 Web-Zugriff
PORTS_NAS Port(s) 445, 2049 SMB, NFS
BLOCK_LIST URL Table URL einer IP-Liste automatisch aktualisierte Sperrliste

6. Regeln richtig bauen

So denkt pfSense

  • Regeln gelten auf dem Interface, auf dem der Verkehr in die Firewall hineinkommt – eine Regel für Gäste gehört also auf das Interface GAESTE, nicht auf WAN.
  • Auswertung von oben nach unten, die erste passende Regel entscheidet.
  • Block verwirft still, Reject antwortet mit einer Ablehnung – intern ist Reject angenehmer, weil Programme nicht in ein Timeout laufen.
  • Floating Rules gelten über mehrere Interfaces hinweg und werden vor den Interface-Regeln ausgewertet – sparsam und nur bewusst einsetzen.
  • Das LAN hat ab Werk eine „Allow LAN to any“-Regel und die Anti-Lockout-Regel für die Weboberfläche.

Beispiel-Regelsätze

Interface LAN (Arbeitsrechner):

# Aktion Quelle Ziel Port Zweck
1 Pass LAN net NAS PORTS_NAS Dateifreigaben
2 Pass ADMIN_HOSTS MGMT net any Verwaltung nur von Admin-Rechnern
3 Reject LAN net RFC1918 any sonst nichts Internes
4 Pass LAN net any any Internet

Interface IOT:

# Aktion Quelle Ziel Port Zweck
1 Pass IOT net IOT address 53 (DNS), 123 (NTP) DNS und Zeit nur über die Firewall
2 Block IOT net This Firewall any kein Zugriff auf die Weboberfläche
3 Block IOT net RFC1918 any keine internen Netze
4 Pass IOT net any PORTS_WEB nur Web ins Internet

Interface GAESTE: wie IOT, aber Regel 4 mit Ziel any / Port any – Gäste dürfen ins Internet, sonst nirgendwohin.


7. NAT: Dienste veröffentlichen

Outbound NAT (Firewall → NAT → Outbound) steht standardmäßig auf Automatic – alle internen Netze werden automatisch auf die WAN-Adresse umgesetzt. Auf Hybrid umstellen, wenn eigene Regeln dazukommen sollen (z. B. für einen VPN-Anbieter).

Port Forward (Firewall → NAT → Port Forward) – Beispiel: Webserver im Servernetz von außen erreichbar machen:

Feld Wert
Interface WAN
Protocol TCP
Destination WAN address
Destination port 443
Redirect target IP 10.10.20.30
Redirect target port 443
Filter rule association Add associated filter rule

8. DNS: der Resolver als Schaltzentrale

pfSense nutzt standardmäßig Unbound als rekursiven Resolver (Services → DNS Resolver). Nützliche Einstellungen:

  • Host Overrides: eigene Namen wie nas.home.arpa → 10.10.20.10
  • DHCP-Registrierung: Clients sind automatisch per Name erreichbar
  • DNSSEC: Antworten werden kryptografisch geprüft
  • Optional DNS over TLS zu einem Upstream-Anbieter (Forwarding-Modus)

Alle Geräte zwingen, den pfSense-DNS zu nutzen – wichtig für IoT-Geräte mit fest eingetragenen DNS-Servern:

  1. Firewall → NAT → Port Forward, Interface IOT
  2. Protokoll TCP/UDP, Quelle IOT net, Ziel NOT IOT address, Port 53
  3. Weiterleiten an 127.0.0.1, Port 53

So landet jede DNS-Anfrage beim Resolver – auch wenn ein Gerät 8.8.8.8 erzwingen will.


9. Fernzugriff mit WireGuard

WireGuard ist schlank, schnell und modern. Auf pfSense wird es als Paket installiert.

Schritt für Schritt (Remote Access):

  1. System → Package Manager → Available Packages: WireGuard installieren.
  2. VPN → WireGuard → Tunnels → Add Tunnel:
    • Listen Port 51820
    • Generate für das Schlüsselpaar der Firewall
    • Tunnel-Adresse z. B. 10.10.50.1/24
  3. Interfaces → Assignments: den Tunnel tun_wg0 als Interface zuweisen, aktivieren, Name WG_VPN.
  4. Firewall → Rules → WAN: Pass, Protokoll UDP, Ziel WAN address, Port 51820.
  5. Firewall → Rules → WG_VPN: festlegen, was VPN-Clients dürfen – z. B. nur SERVER net.
  6. VPN → WireGuard → Peers → Add Peer je Gerät: Public Key des Geräts, Allowed IPs 10.10.50.2/32.

Client-Konfiguration (Beispiel, Schlüssel und Adresse ersetzen):

ini
[Interface]
PrivateKey = <privater-schluessel-des-geraets>
Address = 10.10.50.2/32
DNS = 10.10.50.1

[Peer]
PublicKey = <public-key-der-firewall>
Endpoint = vpn.example.org:51820
# Split Tunnel: nur interne Netze durch den Tunnel
AllowedIPs = 10.10.10.0/24, 10.10.20.0/24, 10.10.50.0/24
# Full Tunnel stattdessen: AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
Modus AllowedIPs beim Client Effekt
Split Tunnel nur interne Netze Internet läuft direkt, nur Heimnetz über VPN – schnell und sparsam
Full Tunnel 0.0.0.0/0 gesamter Verkehr über das Heimnetz – sinnvoll in fremden WLANs

10. pfBlockerNG: Werbung, Tracker und schlechte IPs blocken

pfBlockerNG arbeitet auf zwei Ebenen:

  • IP-Blocking – Verbindungen zu bekannten bösartigen Adressen und Netzen (auch nach Ländern per GeoIP)
  • DNSBL – Domains auf Sperrlisten werden im DNS-Resolver auf eine leere Adresse umgeleitet (Werbung, Tracker, Malware, Phishing)

Einrichtung:

  1. Paket installieren – viele aktuelle Anleitungen empfehlen die Variante pfBlockerNG-devel.
  2. Firewall → pfBlockerNG: Der Assistent startet. Inbound-Interface WAN, Outbound-Interface LAN (weitere Netze später ergänzen).
  3. Nach dem Assistenten sind bereits Reputationslisten aktiv, z. B. Spamhaus DROP/EDROP, Emerging Threats Block und CINS Army.
  4. DNSBL aktivieren und unter Feeds passende Listen wählen (Werbung, Tracker, Malware).
  5. DoH/DoT-Blocking einschalten (DNSBL SafeSearch), damit Browser den Filter nicht über DNS-over-HTTPS umgehen.
  6. Für alle internen Netze unter DNSBL Firewall Rule die Interfaces auswählen.

11. Suricata: Angriffe erkennen und blocken

Suricata ist ein IDS/IPS, das den Verkehr mit Signaturen vergleicht.

  1. Paket Suricata installieren.
  2. Services → Suricata → Global Settings: Regelquellen wählen – z. B. ET Open (Emerging Threats, kostenlos) und die Snort GPLv2 Community Rules; Update-Intervall festlegen.
  3. Interfaces → Add: Interface wählen (meist WAN oder die internen Netze, wenn du auch Verkehr zwischen VLANs prüfen willst).
  4. Zuerst im IDS-Modus (nur melden) laufen lassen und eine Woche die Alerts beobachten.
  5. Fehlalarme über Suppress entfernen, dann Blocking (Legacy-Modus) oder Inline IPS aktivieren.

12. Backups und Updates

Sichern:

Methode Wo Hinweis
Manuell Diagnostics → Backup & Restore XML-Datei herunterladen, vor jeder größeren Änderung
AutoConfigBackup Services → Auto Config Backup verschlüsselte Sicherung bei Netgate, seit CE 2.8 mit überarbeiteter Oberfläche und Schlüsselverwaltung
ZFS Boot Environments (pfSense Plus) System → Boot Environments Zustand vor einem Update, bei Problemen zurück booten – in CE nicht in der Weboberfläche verfügbar

Updaten:

  1. Backup erstellen.
  2. System → Update: Branch auf die aktuelle stabile Version stellen (z. B. Current Stable Version (2.8.1)).
  3. Nicht benötigte Dienste vorher deaktivieren und die Firewall einmal neu starten – das erhöht laut Netgate die Erfolgschancen bei größeren Sprüngen.
  4. Confirm – danach Pakete prüfen. Nur Pakete installieren, die zur eigenen Version passen.

13. Hochverfügbarkeit mit zwei Firewalls

Für Umgebungen, in denen die Firewall nicht ausfallen darf, bilden zwei pfSense-Systeme ein Cluster:

text
            Internet
               │
     ┌─────────┴─────────┐
  fw01 (Master)     fw02 (Backup)
     │   ◄── pfsync ──►   │      dedizierte Sync-Verbindung
     └─────────┬─────────┘
          CARP-VIP 10.10.10.1      ← Gateway für die Clients
Baustein Aufgabe
CARP-VIPs virtuelle Gateway-Adressen, die bei Ausfall zum Backup wandern
pfsync synchronisiert die Verbindungstabelle – laufende Verbindungen bleiben bestehen
XMLRPC-Sync überträgt Regeln, NAT, Aliase usw. vom Master auf das Backup
Kea-HA DHCP-Leases auf beiden Knoten (seit CE 2.8)

Pro Netz werden drei Adressen benötigt (fw01, fw02, CARP-VIP) – auf der WAN-Seite in der Regel mehrere statische IPs vom Provider.


14. Fehlersuche: Symptom → Ursache → Lösung

Symptom Häufige Ursache Lösung
Neues VLAN hat kein Internet keine Regel auf dem VLAN-Interface Pass-Regel anlegen, Outbound NAT prüfen
Clients bekommen keine IP im VLAN DHCP nicht aktiviert oder Switch-Port nicht getaggt DHCP-Server je Interface prüfen, Trunk/Tagging am Switch
Weboberfläche nicht mehr erreichbar LAN-Adresse geändert, Regel gelöscht Konsolenmenü Option 2 (IP) bzw. Anti-Lockout prüfen
pfSense-VM extrem langsam Hardware-Checksum-Offloading aktiv System → Advanced → Networking deaktivieren, neu starten
WireGuard: kein Handshake WAN-Regel fehlt, falscher Port, Schlüssel vertauscht UDP 51820 auf WAN erlauben, Public Keys prüfen
WireGuard verbunden, aber kein Zugriff keine Regel auf WG_VPN, falsche Allowed IPs Regel ergänzen, Netze in AllowedIPs prüfen
Seite lädt nicht seit pfBlockerNG Domain auf einer Sperrliste Reports → Alerts, Domain whitelisten
Verbindung bricht unregelmäßig ab Suricata blockt (Fehlalarm) Alerts/Blocks prüfen, Signatur unterdrücken

Werkzeuge in der Weboberfläche: Diagnostics → Ping / Traceroute / Packet Capture / States / pfTop sowie Status → System Logs → Firewall (Klick auf das Block-Symbol zeigt die verantwortliche Regel).


Checkliste für den produktiven Betrieb

  • Eigener Admin-Benutzer, Standardkonto nicht genutzt, starkes Passwort
  • Weboberfläche und SSH nur aus dem Management-Netz oder per VPN
  • Alle Netze segmentiert, jede Regel beschriftet
  • IoT und Gäste ohne Zugriff auf interne Netze und die Firewall
  • DNS zentral über pfSense, Umgehung blockiert
  • Fernzugriff nur über VPN, keine unnötigen Port-Weiterleitungen
  • pfBlockerNG und ggf. Suricata eingerichtet und getestet
  • Logs an einen Syslog-Server, Speicherplatz im Blick
  • Automatische Backups, Wiederherstellung einmal ausprobiert
  • Update-Routine: Backup → Update → Funktionstest

Weiterführende Quellen