Es gibt diese Tage, an denen man stundenlang nach dem Fehler sucht – Routing? Nein. Firewall? Nein. MTU? Auch nicht. Man beginnt an sich selbst zu zweifeln und überlegt, ob man vielleicht heimlich die ICMP-Götter verärgert hat. Irgendwo müssen diese Errors doch herkommen – irgendwo her muss diese CPU-Last doch herkommen…

In meinem Fall war es zum Glück banaler: Die Netzwerkkarte einer OPNSense-VM.

E1000E vs. Virtio – oder wie man CPU-Last verschenkt

Die OPNSense lief seit jeher mit dem emulierten E1000E-Treiber. Funktioniert gut, ist kompatibel, tut nicht weh. Also der VW Golf unter den NICs: nicht sexy, aber fährt. Unter ESX gebaut wurde fleißig auf Proxmox migriert – und unter Proxmox 8 war auch noch alles fein – seit Proxmox 9 jedoch kam es plötzlich zu einer extremen Last und vielen Errors – aber “nur” auf der Backup-Firewall.

Was ich unterschätzt hatte: Emulierte Hardware bleibt … nun ja, emuliert. Alles, was da reingeht und rausgeht, muss die Virtualisierungsplattform nachbauen. Und das kostet CPU. Viel CPU. Und manchmal erzeugt es Dinge, die man im Netzwerk eigentlich nicht haben möchte: Re-Transmits, Checksum-Errors und dieses feine Gefühl, dass irgendwie alles „ruckelt“. Also habe ich – in einem spontanen Anflug technischer Vernunft – den vNIC-Typ geändert: Virtio.
Kein Voodoo, kein Kernelpatch, einfach nur ein Dropdown gefolgt von einem Reboot der VM.

NICs neu zuweisen, WAN-IP anpassen, kurzer Blick auf die Stats … und plötzlich war Ruhe im Karton. Die Firewall-CPU glühte nicht mehr wie ein Adventskranz auf Stufe 3, sondern pendelte sich gemütlich bei 10 % ein – trotz aktivem IPD/IDS.

Re-Transmits?
Checkum-Errors?
Wie weggeblasen. Ich musste zweimal hinschauen, weil ich dachte, ich wäre auf der primären Maschine gelandet.

Warum Virtio so viel besser funktioniert

Virtio ist keine Emulation, sondern eine paravirtualisierte Schnittstelle. Das heißt:

• Keine emulierten Interrupts
• Keine übermäßige CPU-Last durch Virtualisierungs-Overhead
• Moderne Queuing-Mechanismen (virtio-net ist schneller, stromsparender, belastbarer)
• Und: OPNSense/FreeBSD kann diese Art Treiber (inzwischen) sehr gut nutzen.
  
  Leider weisen viele Foren auf damalige Probleme hin, die in 2025 einfach obsolet und längst gepatched sind.

Kurz: Man spricht direkt mit der Hypervisor-Schicht, statt erst einen Übersetzer anrufen zu müssen, der jedes Paket einzeln in verständliches Deutsch dolmetscht.

Lesson Learned: Wie so oft ist es manchmal einfach nur ein kleines Häkchen

Wenn ihr also Performance-Probleme mit OPNSense habt und eure CPU aussieht wie ein Formel-1-Pitstop – schaut zuerst auf euren NIC-Typ. Bevor man Tage in Packet Captures, pps-Optimierungen oder NIC-Offloading-Folklore versenkt, sollte man diese einfache Stellschraube testen.

Und ja, ich gebe es zu: Dass eine so simple Änderung die Firewall so nachhaltig beruhigt hat, fühlt sich ein bisschen wie ein Cheat-Code an. Aber ich nehme den Sieg. 😄