Die Intel I226-V NIC auf einer pfSense stalled sporadisch für Sekunden. Klingt harmlos — bis du merkst, dass die Kerberos-Tickets ablaufen, DFS auf NTLM zurückfällt und Active-Directory-Accounts gesperrt werden. Weil ein Umlaut im Benutzernamen ist.
WireGuard Road-Warrior-VPN auf pfSense eingerichtet, Handshake steht — aber kein Traffic kommt durch. Drei nicht-offensichtliche Ursachen: Interface-IP verschwindet nach Assignment, Firewall-Gruppen-Regeln greifen nicht mehr, und NetworkManager bricht dein Internet-DNS.
Ausgehende Mails kamen eine Woche lang nicht an — ohne jede Fehlermeldung. Suricata hatte die Smarthost-IP in die snort2c-Blocktabelle geschrieben. Die Passlist enthielt die IP, aber im Legacy IPS pcap-Mode schützt sie nicht vor Blocking. Fix: Suppress-Regel, Cron-Guard und Zabbix-Monitoring.
PBS-Restores über OpenVPN schaffen nur 3 MB/s — ein architektonisches Limit. WireGuard bringt deutlich mehr Throughput, aber die Migration über pfSense hat drei nicht-offensichtliche Fallen: filter_configure() killt VPN-Sessions, tun0 bleibt nach dem Stoppen stehen, und deine neue Tunnel-IP muss ins bestehende /30 passen.
NordVPN WireGuard-Tunnel auf pfSense tot — kein Internet für alle Clients, Gateway-Group failovert nicht. Drei nicht-offensichtliche Ursachen: dpinger pingt sich selbst, Subnetzmaske /32 statt /16, und der NordVPN-Endpoint ist einfach weg. Plus: Wie du den WireGuard-Key ohne die NordVPN-API registrierst.
Suricata auf pfSense mit blockoffenders aktiv — und täglich Totalausfall der gesamten Hetzner-Infrastruktur. Die eigene WAN-IP stand in der snort2c-Tabelle. Ursache: leere Passlist (wanaddr/lanaddr/vpnaddr fehlten), kaputte Passlist-Referenz aus der Snort-Migration, und Snort lief parallel noch mit.
Snort 2.9.x ist End-of-Life. Wer auf pfSense noch Snort betreibt, sollte jetzt auf Suricata wechseln. Dieser Artikel zeigt wie die Migration vollautomatisch via PHP-API funktioniert — inkl. der drei Fallen die mich Stunden gekostet haben.
Firewall-Regel via PHP in config.xml geschrieben, filter_configure() aufgerufen, pf zeigt nichts. Kein Fehler, keine Warnung. Der Grund: ein leerer PHP-String im ‘disabled’-Key. Ein isset()-Gotcha das Stunden kostet.
pfSense hat eine PHP-API die direkt auf config.xml operiert. Klingt verlockend für Automatisierung — ist es auch, aber mit Fallstricken die nirgendwo dokumentiert sind. Hier sind die Patterns und Pitfalls die ich beim Härten einer pfSense-Installation gelernt habe.
Alle Clients offline nach WireGuard-Reconnect, aber pfSense meldet ‘online’. Ursache: dpinger pingt bei WireGuard-Gateways ohne Monitor-Target die eigene Interface-IP – und die antwortet immer, auch wenn der Tunnel tot ist.