pfSense Firewall Regeln: Dein Guide für sichere Heimnetzwerke

Na, alter Hase oder frischer Neuling im Homelab-Dschungel? Schön, dass du den Weg zu smoth.me gefunden hast! Heute tauchen wir tief in ein Thema ein, das oft als trocken abgestempelt wird, aber das Herzstück jeder sicheren Netzwerkumgebung ist: pfSense Firewall-Regeln. Wenn du wie ich schon seit Jahren mit Proxmox, Docker und all den feinen Dingen jonglierst, weißt du, dass die beste Infrastruktur nutzlos ist, wenn die Sicherheit ein Scheunentor hat.

Ich hab's selbst erlebt: Die anfängliche Euphorie, wenn der neue Proxmox-Cluster läuft und Docker-Container wie am Schnürchen tanzen. Dann kommt der Moment, wo du merkst: "Moment mal, das ist ja alles wild offen!" Und genau da kommt pfSense ins Spiel. Eine gut konfigurierte Firewall ist dein erster und wichtigster Verteidigungsring. Und glaub mir, die Regeln richtig zu setzen, ist keine Raketenwissenschaft, aber es erfordert ein klares Verständnis.

In diesem Guide zeige ich dir, wie du Schritt für Schritt deine pfSense Firewall-Regeln erstellst. Das ist kein theoretisches Bla-Bla, sondern handfeste Praxis, genau so, wie ich es in meinem eigenen Homelab mache und wie ich es unzähligen Malen schon für andere eingerichtet habe. Also, schnall dich an, wir legen los!

Voraussetzungen: Was du mitbringen solltest

Bevor wir uns ins Getümmel stürzen, lass uns kurz checken, ob du alles am Start hast:

Eine laufende pfSense-Instanz: Das ist natürlich die Basis. Egal ob auf dedizierter Hardware (die N305 oder N100 Barebones sind da echt schicke kleine Kisten, die ich auch gerne empfehle) oder als VM auf Proxmox – Hauptsache, pfSense läuft und du hast Zugriff auf die WebGUI.
Zugriff auf die pfSense WebGUI: Du solltest dich mit einem Browser auf deiner pfSense-Instanz anmelden können (Standard ist oft https://192.168.1.1/ oder was du eben konfiguriert hast).
Grundkenntnisse in Netzwerktechnik: Keine Angst, du musst kein CCIE sein. Aber ein Verständnis von IP-Adressen, Subnetzen (CIDR-Notation), Ports (z.B. 80 für HTTP, 443 für HTTPS) und Protokollen (TCP, UDP, ICMP) ist extrem hilfreich. Wer das zum ersten Mal einrichtet, stolpert oft über diese Basics. Mein Tipp: Frische dein Wissen auf, wenn du unsicher bist.
Ein grobes Konzept: Überlege dir, was du erreichen möchtest. Welcher Dienst soll von wo nach wo erreichbar sein? Was soll definitiv blockiert werden? Das erspart dir später viel Kopfzerbrechen und unnötiges Rumprobieren.

Grundlagen der pfSense Firewall-Regeln: Dein Sicherheits-ABC

Bevor wir auf "Add" klicken, lass uns kurz über die Logik hinter pfSense-Regeln sprechen. Stell dir die Firewall wie einen Türsteher vor, der eine Liste von Anweisungen hat. Jede Regel ist eine dieser Anweisungen.

Regelverarbeitung und Reihenfolge: pfSense arbeitet Regeln von oben nach unten ab. Sobald eine Regel zutrifft, wird sie angewendet und die weitere Prüfung stoppt. Das ist extrem wichtig zu verstehen! Eine zu allgemeine Regel oben kann spezifischere Regeln weiter unten unwirksam machen.
Interfaces: Jede Regel ist an ein bestimmtes Interface gebunden (z.B. LAN, WAN, OPT1 für ein DMZ oder IoT-Netz). Traffic, der über dieses Interface reinkommt, wird gegen die dort definierten Regeln geprüft.
Standardregeln: pfSense bringt schon ein paar Standardregeln mit. Auf dem LAN-Interface ist die Standardregel in der Regel "alles raus" (Pass any from LAN net to any). Das bedeutet, dass alle Geräte in deinem LAN standardmäßig Zugriff auf das Internet haben. Auf dem WAN-Interface ist es standardmäßig restriktiver: "alles rein" wird geblockt, es sei denn, es ist eine Antwort auf eine ausgehende Verbindung oder explizit per Port Forwarding erlaubt.
Action (Aktion):
- Pass: Der Traffic darf passieren.
- Block: Der Traffic wird stumm verworfen (wie ein Dieb, der an die Tür klopft und niemand antwortet). Der Absender erhält keine Rückmeldung.
- Reject: Der Traffic wird verworfen, aber dem Absender wird eine Fehlermeldung (z.B. ICMP Port Unreachable oder TCP RST) gesendet. Das kann hilfreich sein, um den Absender wissen zu lassen, dass der Dienst nicht erreichbar ist, aber es verrät auch, dass da *etwas* ist. Ich persönlich nutze meistens Block für unerwünschten externen Traffic und Reject intern, um Fehlersuche zu erleichtern.

Schritt-für-Schritt: Deine erste pfSense Firewall-Regel erstellen

Jetzt wird's ernst! Wir loggen uns ein und erstellen eine Beispielregel. Nehmen wir an, du möchtest sicherstellen, dass dein LAN-Netzwerk HTTP- und HTTPS-Verbindungen ins Internet aufbauen darf. Ja, ich weiß, das ist meist schon standardmäßig erlaubt, aber es ist ein super Beispiel, um die Komponenten einer Regel zu verstehen.

1. Login in die WebGUI

Öffne deinen Browser und navigiere zur IP-Adresse deiner pfSense-Instanz (z.B. https://192.168.1.1/). Melde dich mit deinen Zugangsdaten an.

2. Navigation zu "Firewall" -> "Rules"

Oben im Menü findest du den Punkt Firewall. Klick darauf, und im Untermenü wählst du Rules.

Du siehst nun eine Liste deiner Interfaces (WAN, LAN, OPT1, etc.). Wähle das Interface aus, für das du eine Regel erstellen möchtest. In unserem Fall ist das LAN, da der Traffic von unserem LAN-Netzwerk ausgehen soll.

3. Regel hinzufügen

Auf der Seite des LAN-Interfaces siehst du oben und unten einen Add-Button (mit einem Pluszeichen). Klicke auf den Button, um eine neue Regel hinzuzufügen. Der obere Button fügt die Regel ganz oben ein, der untere ganz unten. Die Position ist wichtig, denk an die Regelverarbeitung!

4. Die Regel konfigurieren – Schritt für Schritt

Jetzt öffnet sich das Formular für die neue Regel. Hier definierst du, was passieren soll.

Action:
Wähle Pass. Wir wollen ja, dass der Traffic durchkommt.
Interface:
Hier sollte schon LAN ausgewählt sein, da wir die Regel auf dem LAN-Tab erstellt haben. Wenn nicht, wähle es aus. Das bedeutet, diese Regel gilt für Traffic, der *auf* dem LAN-Interface *ankommt*.
Address Family:
Meistens wirst du IPv4 wählen. Wenn du ein reines IPv6-Netzwerk hast oder beides nutzen möchtest, wählst du entsprechend IPv6 oder IPv4+IPv6.
Protocol:
Für HTTP und HTTPS nutzen wir TCP. Wenn du zum Beispiel Pings erlauben willst, wäre es ICMP. Wenn du unsicher bist, kannst du auch Any wählen, aber das ist aus Sicherheitssicht nicht ideal. Sei so spezifisch wie möglich!
Source (Quelle):
Wer darf diese Verbindung aufbauen? In unserem Fall soll es das gesamte LAN-Netzwerk sein. Wähle daher LAN net. Du könntest hier auch einen Single Host or Alias angeben, wenn nur ein bestimmter Server oder eine Gruppe von Geräten (definiert über ein Alias) ins Internet darf.
Destination (Ziel):
Wohin soll die Verbindung gehen? Wir wollen ja ins gesamte Internet, also wähle any. Wenn du nur Zugriff auf einen bestimmten externen Server erlauben möchtest, würdest du hier dessen IP-Adresse oder einen Alias hinterlegen.
Destination Port Range (Ziel-Portbereich):
Welche Ports sollen auf dem Ziel erreichbar sein? Für HTTP und HTTPS sind das Port 80 und Port 443. Hier kannst du unter "From" und "To" die entsprechenden Ports auswählen oder manuell eingeben. pfSense hat praktische Aliase für bekannte Dienste wie HTTP oder HTTPS. Wähle also:
- HTTP (Port 80) für "From" und "To"
- Klicke auf den Add-Button daneben, um einen weiteren Portbereich hinzuzufügen.
- Wähle HTTPS (Port 443) für "From" und "To"
Das hat mir viel Zeit gespart: Nutze die vordefinierten Port-Aliase! Das macht die Regeln lesbarer und du tippst dich nicht so schnell daneben.
Description (Beschreibung):
Ganz wichtig! Gib der Regel einen aussagekräftigen Namen, z.B. Allow LAN to WAN HTTP/HTTPS. Glaub mir, in sechs Monaten weißt du sonst nicht mehr, wofür die Regel war. Ein gut gepflegtes Regelwerk ist Gold wert!

Dein Regel-Setup könnte dann, konzeptionell, so aussehen:

Action: Pass
Interface: LAN
Address Family: IPv4
Protocol: TCP
Source: LAN net
Destination: any
Destination Port Range:
  From: HTTP (80) To: HTTP (80)
  From: HTTPS (443) To: HTTPS (443)
Description: Allow LAN to WAN HTTP/HTTPS

5. Speichern und Anwenden

Klicke unten auf Save. Danach siehst du einen gelben Balken mit der Aufforderung Apply Changes. Klick auch darauf, damit die Regel tatsächlich von der Firewall geladen und aktiv wird. Wenn du das vergisst, wunderst du dich, warum nichts funktioniert!

Praktische Beispiele für Regeln: Dein Werkzeugkasten

Jetzt, wo du die Grundlagen kennst, schauen wir uns ein paar Szenarien an, die du im Homelab oft brauchen wirst.

Beispiel 1: Zugriff auf einen internen Webserver von LAN erlauben

Stell dir vor, du hast einen Nginx-Container auf deinem Proxmox-Host (IP: 192.168.1.100) und möchtest, dass alle deine LAN-Geräte darauf zugreifen können.

Action: Pass
Interface: LAN (Traffic kommt vom LAN)
Address Family: IPv4
Protocol: TCP
Source: LAN net
Destination: Single Host or Alias, gib hier die IP deines Nginx-Containers ein (192.168.1.100)
Destination Port Range: HTTP (80) und HTTPS (443)
Description: Allow LAN to internal Nginx

Das ist eine sehr häufige Regel, um interne Dienste zu öffnen.

Beispiel 2: Zugriff auf das pfSense WebGUI von einem spezifischen Host erlauben

Aus Sicherheitsgründen möchte ich nicht, dass jeder im LAN auf das pfSense WebGUI zugreifen kann. Nur mein Admin-PC (192.168.1.50) soll das dürfen. Diese Regel muss *über* der Standard-Allow-LAN-to-any-Regel liegen, falls eine solche existiert und du den Zugriff weiter einschränken willst.

Action: Pass
Interface: LAN
Address Family: IPv4
Protocol: TCP
Source: Single Host or Alias, gib hier die IP deines Admin-PCs ein (192.168.1.50)
Destination: This Firewall (self) (pfSense hat einen Alias dafür)
Destination Port Range: HTTPS (443)
Description: Allow Admin-PC to pfSense WebGUI

Danach könntest du eine Block-Regel einfügen, die jeglichen anderen Zugriff auf This Firewall (self) auf Port 443 vom LAN net blockiert. Denk an die Reihenfolge!

Beispiel 3: Zugriff auf bestimmte externe Dienste sperren

Du möchtest verhindern, dass Geräte in deinem IoT-Netzwerk (z.B. auf OPT1) auf Social Media zugreifen können (angenommen, du hast eine IP-Liste für Social Media in einem Alias SocialMedia_IPs).

Action: Block
Interface: OPT1 (Traffic kommt vom IoT-Netz)
Address Family: IPv4
Protocol: TCP
Source: OPT1 net
Destination: Single Host or Alias, wähle hier deinen Alias SocialMedia_IPs
Destination Port Range: HTTP (80) und HTTPS (443)
Description: Block IoT to Social Media

Diese Regel muss vor jeder "Allow any" Regel auf dem OPT1-Interface stehen, sonst greift sie nicht!

Regel-Reihenfolge – Dein bester Freund und schlimmster Feind

Ich kann es nicht oft genug betonen: Die Reihenfolge deiner Regeln ist der Schlüssel! pfSense verarbeitet Regeln von oben nach unten. Die erste Regel, die auf den Traffic zutrifft, wird angewendet, und weitere Regeln werden ignoriert.

Mein Tipp: Denk an "spezifisch vor generell". Wenn du zum Beispiel den Zugriff auf Port 80 für einen bestimmten Host blockieren möchtest, aber eine generelle "Allow any to any on Port 80" Regel weiter oben steht, wird deine Block-Regel niemals greifen. Du kannst Regeln per Drag-and-Drop in der WebGUI verschieben, um ihre Reihenfolge anzupassen. Nach dem Verschieben immer Apply Changes nicht vergessen!

Häufige Fehler und Lösungen

Jeder Admin stolpert mal. Hier sind ein paar Klassiker, die mir und meinen Kollegen immer wieder begegnen:

1. Regel erstellt, aber vergessen "Apply Changes" zu klicken

Problem: Du hast eine Regel gespeichert, aber der Traffic geht immer noch nicht durch (oder wird immer noch geblockt). Lösung: Prüfe, ob oben in der WebGUI der gelbe Balken mit Apply Changes erscheint. Wenn ja, klick drauf! pfSense lädt die Regeln erst nach diesem Schritt in den aktiven Firewall-Kernel.

2. Falsche Reihenfolge der Regeln

Problem: Eine spezifische Block-Regel greift nicht, weil eine allgemeinere Allow-Regel darüber steht. Oder umgekehrt. Lösung: Geh zu Firewall -> Rules für das betreffende Interface. Prüfe die Reihenfolge. Du kannst Regeln per Drag-and-Drop verschieben. Platziere spezifischere Regeln (z.B. "Block Host A zu Dienst X") immer vor allgemeineren Regeln (z.B. "Allow LAN zu Dienst X").

3. Source/Destination vertauscht oder falsch konfiguriert

Problem: Du willst Traffic von A nach B erlauben, hast aber versehentlich B als Source und A als Destination konfiguriert. Oder du hast "Single Host" statt "Network" gewählt. Lösung: Überprüfe deine Regelkonfiguration genau. Denk daran: Source ist der Absender, Destination ist der Empfänger. Wenn du ein ganzes Subnetz ansprechen willst, nutze Network und gib die CIDR-Notation an (z.B. 192.168.1.0/24). Für einzelne Geräte nutze Single Host or Alias.

Nachdem du eine Regel erstellt hast, ist Testen das A und O. Stell dir vor, du hast eine Regel erstellt, die HTTP-Zugriff auf deinen internen Webserver erlauben soll. Dann versuchst du natürlich, diesen Server von deinem Client aus zu erreichen. Ein einfacher ping zeigt dir, ob die Basiskonnektivität steht, aber für HTTP brauchst du mehr. Hier ein schneller Test von deinem Client:

ping 192.168.1.100 # Prüfen, ob der Server erreichbar ist
curl http://192.168.1.100 # Prüfen, ob der Webserver antwortet

Wenn eine Regel nicht greift, werfe ich als Erstes einen Blick in die Firewall-Logs. Du findest sie unter Status -> System Logs -> Firewall. Manchmal hilft es auch, direkt auf der pfSense-Shell nachzusehen, ob die Regeln geladen wurden. Das ist zwar eher für Fortgeschrittene, aber ein pfctl -s rules zeigt dir die aktuell aktiven Regeln.

# Auf der pfSense Shell (via SSH oder Console)
pfctl -s rules | grep "192.168.1.100" # Sucht nach Regeln, die eine bestimmte IP betreffen

Manchmal liegt es nicht nur an der Firewall. Wenn du Probleme hast, eine Ressource zu erreichen, checke immer die Routing-Tabelle und die Erreichbarkeit mit Tools wie traceroute.

traceroute example.com # Zeigt den Weg zu einem Ziel

4. Port vergessen oder falsch angegeben

Problem: Die Verbindung klappt nicht, obwohl die IP-Adressen stimmen. Lösung: Hast du den richtigen Port (oder die richtigen Ports) angegeben? Ist es TCP oder UDP? Manchmal ist es ein kleiner Zahlendreher, manchmal vergisst man, dass ein Dienst nicht auf dem Standardport läuft. Prüfe auch, ob der Dienst auf dem Zielsystem überhaupt auf dem Port lauscht.

5. Interface-Fehler

Problem: Du hast eine Regel auf dem falschen Interface erstellt. Lösung: Eine Regel auf dem LAN-Interface regelt Traffic, der *auf* dem LAN-Interface *ankommt*. Wenn dein Traffic von einem anderen Netz (z.B. OPT1) kommt, muss die Regel auch auf dem OPT1-Interface liegen.

Fazit & Nächste Schritte

Uff, das war jetzt eine ordentliche Portion Wissen, oder? Aber ich hoffe, du hast gemerkt, dass das Erstellen von pfSense Firewall-Regeln keine Hexerei ist. Es ist ein Handwerk, das mit Verständnis der Grundlagen und ein bisschen Übung schnell zur zweiten Natur wird. Die Sicherheit deines Homelabs und Netzwerks hängt maßgeblich davon ab, wie gut du diese Regeln beherrschst. Und mal ehrlich, das Gefühl, ein rocksolides, sicheres Netzwerk zu haben, ist doch unbezahlbar!

Was kommt als Nächstes, nachdem du die Regeln im Griff hast? Hier ein paar Ideen:

Aliases nutzen: Erstelle Aliase für Hosts, Netzwerke und Ports. Das macht deine Regeln viel übersichtlicher und einfacher zu verwalten.
NAT und Port Forwarding: Wenn du Dienste von außen erreichbar machen willst, kommst du um NAT (Network Address Translation) und Port Forwarding nicht herum. Ein Thema für einen weiteren Guide!
VLANs und Multi-Interface-Setups: Trenne dein Netzwerk in logische Segmente (z.B. IoT, Gäste, Server). Das erhöht die Sicherheit und die Übersichtlichkeit enorm.
Intrusion Detection/Prevention Systeme (IDS/IPS): Tools wie Suricata können dein Netzwerk auf bösartigen Traffic überwachen und sogar blockieren.

Bleib dran, experimentiere, und hab keine Angst, Fehler zu machen – daraus lernt man am meisten. Und wenn du mal feststeckst, die Community hilft immer gerne!

Happy homelabbing und bis zum nächsten Mal!