Intel I226-V auf pfSense: Wie PCIe-Energiesparen deine NICs killt und Active Directory gleich mit

Die Kassen gehen nicht. Kein DNS, keine Netzlaufwerke, nichts. Dann, 30 Sekunden später, ist alles wieder da. Jeden Tag, manchmal mehrmals.

Du checkst die Firewall-Logs. Nichts. Kein Paket-Drop, kein Block. Der VPN-Tunnel steht. Die Interfaces sind UP. Alles sieht gut aus.

Bis du merkst: der Link war 3 Sekunden DOWN. Und in diesen 3 Sekunden hat Active Directory beschlossen, dass der Benutzer “müller2” sein Passwort falsch eingegeben hat. Fünf Mal.

Das Setup

pfSense 2.7.2 auf einem Mini-PC mit vier Intel I226-V NICs (igc-Treiber). Gateway für eine Filiale, VPN zur Zentrale, DHCP und DNS für ~8 LAN-Geräte.

Das Problem existiert seit Wochen. Sporadisch. Unvorhersehbar. Der klassische Netzwerk-Geist.

Diagnose: Wie findet man einen 3-Sekunden-Ausfall?

Schritt 1: Sichtbar machen

Die pfSense hat dmesg, aber der zeigt nur den aktuellen Ring-Buffer. Beim nächsten Boot weg. Wir brauchen einen persistenten Logger.

FreeBSD’s devd reagiert auf Kernel-Events — auch auf Link-State-Changes:

# /usr/local/etc/devd/igc1-monitor.conf
notify 0 {
    match "system"    "IFNET";
    match "type"      "LINK_DOWN";
    match "subsystem" "igc1";
    action "/usr/local/bin/igc1-linkstate.sh DOWN";
};

notify 0 {
    match "system"    "IFNET";
    match "type"      "LINK_UP";
    match "subsystem" "igc1";
    action "/usr/local/bin/igc1-linkstate.sh UP";
};

Das Script loggt Zeitstempel + Event nach /var/log/igc1-linkstate.log. Dazu ein Watchdog per Cron (jede Minute) der den Switch pingt und igc1 bounced wenn er nicht antwortet.

Schritt 2: Zabbix dranhängen

Vier UserParameters auf der pfSense:

UserParameter=igc1.linkdown.total,awk '/LINK_DOWN/{n++}END{print n+0}' /var/log/igc1-linkstate.log 2>/dev/null || echo 0
UserParameter=igc1.link.running,ifconfig igc1 | grep -c RUNNING
UserParameter=igc1.watchdog.bounces,awk '/bounce/{n++}END{print n+0}' /var/log/igc-watchdog.log 2>/dev/null || echo 0
UserParameter=igc1.watchdog.heartbeat.age,<perl-oneliner>

Trigger: Link-Down-Counter steigt → High Alert. Recovery basiert auf dem Live-Status (igc1.link.running=1), nicht auf dem Log — weil der UP-Event manchmal so schnell kommt, dass devd ihn nicht mitbekommt.

Ergebnis: 13 Drops an einem Tag

2026-03-25 14:44:15 igc1 LINK_DOWN
2026-03-25 14:58:22 igc1 LINK_DOWN
2026-03-25 20:08:12 igc1 LINK_DOWN
2026-03-25 21:37:03 igc1 LINK_DOWN
2026-03-25 21:38:38 igc1 LINK_DOWN
2026-03-25 21:38:48 igc1 LINK_DOWN
...

9 Drops in 6 Minuten um 21:37 — genau zur Backup-Zeit. Hoher Traffic → PCIe wechselt Power-States → NIC stalled.

Die Ursache: ASPM

ASPM (Active State Power Management) erlaubt dem PCIe-Bus, die Verbindung zur NIC in einen Schlafmodus zu versetzen. Beim Aufwachen geht der Link kurz verloren.

sysctl hw.pci.enable_aspm
hw.pci.enable_aspm: 1    ← AN. Das ist das Problem.

Das ist ein bekanntes Problem bei der Intel I226-V. Intel hat es bestätigt, der FreeBSD-Bugtracker ist voll davon, und das OPNsense-Forum hat einen SOLVED-Thread.

Fix

# In /boot/loader.conf:
hw.pci.enable_aspm=0

Reboot erforderlich (read-only Tunable, kein sysctl zur Laufzeit). Danach: null Drops in 21+ Stunden, inklusive Backup-Zeit.

Achtung: EEE (Energy Efficient Ethernet) und Flow Control waren bereits deaktiviert (dev.igc.*.eee_control=0, dev.igc.*.fc=0). Das allein reichte nicht. ASPM war der fehlende Baustein.

Plot Twist: Account-Lockouts

Die NIC-Stalls waren behoben. Aber die Kassen-Benutzer sperrten sich weiterhin. Alle 20 Minuten. Auch nachts.

Die Kaskade

1. NIC stalled → LAN-Geräte verlieren kurz die Verbindung
2. Kerberos-Tickets werden ungültig (kein DC erreichbar während Stall)
3. Windows greift auf \\darkside.local\DFS\ zu (Ordnerumleitung)
4. Kerberos sucht SPN cifs/darkside.local → existiert nicht
5. Fallback auf NTLM
6. NTLM-Hash-Berechnung mit Umlaut im Benutzernamen → schlägt fehl
7. DC sagt “falsches Passwort” → Account gesperrt

Beweis: NTLM Operational Log

Windows hat ein verstecktes Gold-Log: Microsoft-Windows-NTLM/Operational. Da steht alles:

Process Name: SYSTEM
Username: müller2
Target Resource: cifs/darkside.local
Reason: The target name could not be resolved by Kerberos

Alle 2 Minuten. Von der Kasse, als SYSTEM-Prozess.

Warum nur diese Benutzer?

Alle Filialen haben das gleiche Problem (fehlender SPN → NTLM-Fallback). Aber nur die Benutzer mit ö im sAMAccountName bekommen Lockouts. Bei allen anderen klappt der NTLM-Fallback zufällig.

Der Fix

setspn -S cifs/darkside.local DC-OBIWAN

Registriert den SPN → Kerberos funktioniert für DFS → kein NTLM-Fallback → keine Lockouts.

Lessons Learned

1. Ein 3-Sekunden-Ausfall kann eine Katastrophe sein

Link-Drop → Kerberos → NTLM → Umlaut → Lockout. Jede Stufe sieht harmlos aus. Die Kombination sperrt Benutzer.

2. devd ist dein Freund auf FreeBSD

Polling per Cron verpasst schnelle Drops. devd reagiert in Echtzeit auf Kernel-Events. Zusammen mit Zabbix-UserParameters hast du ein vollständiges Monitoring-Setup in 20 Minuten.

3. ASPM ist der häufigste I226-V-Killer

EEE deaktivieren reicht nicht. Flow Control deaktivieren reicht nicht. ASPM muss auch raus. Und das geht nur per Reboot (hw.pci.enable_aspm=0 in loader.conf).

4. Fehlende SPNs fallen erst auf wenn es wehtut

cifs/<DEINE-DOMAIN> sollte auf jedem DC registriert sein. Prüf es:

setspn -Q cifs/<DEINE-DOMAIN>

Wenn “No such SPN found” → Kerberos funktioniert nicht für DFS, und du merkst es erst wenn ein Benutzer ein ö im Namen hat.

5. Das NTLM Operational Log existiert

Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" zeigt jeden NTLM-Versuch mit Prozessname, Ziel und Grund. Essentiell bei der Jagd auf Account-Lockouts.

Checkliste: Intel I226-V auf pfSense/FreeBSD

• sysctl hw.pci.enable_aspm → muss 0 sein
• sysctl dev.igc.*.eee_control → muss 0 sein
• sysctl dev.igc.*.fc → muss 0 sein
• devd Link-State-Monitor eingerichtet
• Watchdog-Cron aktiv (jede Minute)
• Zabbix/Monitoring für Link-Down-Events
• setspn -Q cifs/<DEINE-DOMAIN> → SPN muss existieren