Sophos Firewall unter Proxmox ist langsam: Warum VirtIO statt e1000 den Durchsatz um das 20-Fache steigert

Wenn eine Firewall als virtuelle Maschine unter Proxmox läuft und alles dahinter nur mit 30 bis 40 Mbit/s ins Internet kommt, obwohl der Server mit 1 Gbit/s angebunden ist, liegt der Engpass oft in den virtuellen Netzwerkkarten der Firewall-VM. Bei mir waren es zwei e1000-Karten mit aktivierter Proxmox-Firewall. Nach dem Wechsel auf VirtIO und firewall=0 stieg der Durchsatz um den Faktor 17 bis 22.

Stand: 10.10.2026

Auf einen Blick

• Der Proxmox-Host selbst schaffte 920 Mbit/s Download und 518 Mbit/s Upload, die Server hinter der Firewall-VM nur 32 und 40 Mbit/s.
• Die Ursache waren zwei emulierte e1000-Karten mit firewall=1 an der Firewall-VM.
• Die Umstellung dauert wenige Minuten, braucht aber einen vollständigen Stopp der VM und damit eine kurze Unterbrechung für alles dahinter.
• Nach dem Wechsel erreichten die Nodes 533 Mbit/s im Download und 865 Mbit/s im Upload (jeweils vier Verbindungen).

1. Die Ausgangslage: eine Firewall-VM vor einem Kubernetes-Cluster

Ich betreibe einen kleinen Kubernetes-Cluster (ein Master, drei Worker) auf einem einzelnen gemieteten Server mit Proxmox. Vor dem Cluster steht eine Firewall als eigene VM, alle Worker hängen über eine interne Bridge dahinter. Das ist bequem, hat aber einen Preis: Jedes Byte ins Internet läuft durch diese eine VM.

Aufgefallen ist das Problem, als ein Backup der Cluster-Volumes in einen S3-Speicher nur mit 0,28 MB/s lief. Ein Volume mit gut 360 MB brauchte rund 21 Minuten. Das konnte nicht an der Gegenstelle liegen, also habe ich systematisch gemessen.

2. Systematisch messen: Host, Netz, Node

Die wichtigste Regel: Miss immer dort, wo das Problem liegt, und vergleiche von innen nach außen. Ich habe in drei Stufen gemessen.

Stufe 1: Die Verbindung zwischen den Nodes

Mit iperf3 zwischen zwei Workern prüfst du, ob das interne Netz in Ordnung ist. Auf dem einen Node startest du den Server, auf dem anderen den Client:

iperf3 -s -p 5301
iperf3 -c <IP-des-Servers> -p 5301 -t 8 -P 4

Ergebnis bei mir: 9,2 Gbit/s mit einer Verbindung und 15,8 Gbit/s mit vier. Das interne Netz war also nicht das Problem.

Stufe 2: Der Proxmox-Host direkt

Danach habe ich auf der Proxmox-Shell den Internetzugang des Hosts selbst getestet, ohne Firewall-VM dazwischen:

curl -s -o /dev/null -w "%{speed_download} Byte/sn" http://cachefly.cachefly.net/100mb.test
head -c 40000000 /dev/zero | curl -s -o /dev/null -w "%{speed_upload} Byte/sn" -X POST --data-binary @- https://speed.cloudflare.com/__up

Ergebnis: 115 MB/s im Download (rund 920 Mbit/s) und 65 MB/s im Upload (rund 518 Mbit/s). Der Server und seine Anbindung waren also in Ordnung.

Stufe 3: Ein Pod hinter der Firewall

Dieselben beiden Befehle habe ich in einem Pod mit Host-Netzwerk auf einem Worker ausgeführt. Ergebnis: 4 MB/s im Download (32 Mbit/s) und 5 MB/s im Upload (40 Mbit/s). Mehr parallele Verbindungen brachten nichts, die Grenze war hart. Damit war klar: Der Engpass sitzt zwischen Host und Worker, also in der Firewall-VM.

3. Die Ursache: e1000 und die Proxmox-Firewall an der Karte

Ein Blick in die VM-Konfiguration auf dem Proxmox-Host zeigt, wie die Firewall-VM angebunden ist:

qm config 100 | grep -E "^(net|cores|memory)"
cores: 3
memory: 5098
net0: e1000=BC:24:11:xx:xx:xx,bridge=vmbr1,firewall=1
net1: e1000=BC:24:11:xx:xx:xx,bridge=vmbr2,firewall=1

Zwei Dinge fallen auf:

• e1000 ist eine emulierte Intel-Netzwerkkarte. Sie funktioniert mit fast jedem Gast, wird aber vollständig in Software nachgebaut und verbraucht dafür CPU-Zeit. Das empfohlene Modell für virtuelle Maschinen ist VirtIO, eine paravirtualisierte Karte (siehe die Proxmox-Dokumentation zu QEMU/KVM).
• firewall=1 schaltet die Proxmox-Firewall vor die Karte. Bei einer VM, die selbst eine Firewall ist, wird der Verkehr damit zusätzlich vom Host gefiltert. Das ist doppelte Arbeit ohne Nutzen.

4. Die Umstellung Schritt für Schritt

Die Firewall-VM ist das Gateway für alles dahinter. Plane die Umstellung deshalb für ein ruhiges Zeitfenster; rechne mit einigen Minuten Unterbrechung.

1. Snapshot anlegen, damit du jederzeit zurückkannst:

   qm snapshot 100 vor-virtio

2. VM sauber herunterfahren, am besten über die Oberfläche der Firewall selbst oder mit qm shutdown 100.
3. Karten umstellen und dabei die MAC-Adressen beibehalten, damit die Firewall ihre Ports wiedererkennt. Gleichzeitig wird die Proxmox-Firewall an der Karte ausgeschaltet:

   qm set 100 --net0 virtio=BC:24:11:xx:xx:xx,bridge=vmbr1,firewall=0
   qm set 100 --net1 virtio=BC:24:11:xx:xx:xx,bridge=vmbr2,firewall=0

4. VM starten und etwa zwei Minuten warten, bis die Firewall oben ist:

   qm start 100

5. Alles dahinter prüfen: Sind alle Hosts erreichbar? Laufen die Dienste?

Wenn etwas nicht stimmt, stellst du den alten Zustand wieder her:

qm stop 100
qm rollback 100 vor-virtio
qm start 100

5. Das Ergebnis: Faktor 17 bis 22

Nach dem Neustart habe ich dieselben Messungen aus einem Pod wiederholt:

Auch die Backups meiner Cluster-Volumes laufen seitdem normal. Wie du solche Backups für K3s einrichtest, zeigt der Artikel K3s Backup: etcd-Snapshot erstellen.

6. Die wichtigsten Stolperfallen

Alles hängt an dieser einen VM

Während die Firewall-VM heruntergefahren ist, sind alle Dienste dahinter nicht erreichbar. Wer sich auf der Kommandozeile des Proxmox-Hosts bewegt, kommt weiter, aber ohne Firewall bleibt auch jede Web-Oberfläche stumm. Lege den Snapshot an, bevor du irgendetwas anderes tust.

Ein Neustart im Gast reicht nicht

Das Kartenmodell ist Teil der virtuellen Hardware. Es ändert sich erst, wenn die VM vollständig gestoppt und neu gestartet wird, nicht bei einem Reboot im Gastsystem.

MAC-Adressen beibehalten

Ich habe in den Befehlen die bestehenden MAC-Adressen übernommen. So erkennt die Firewall ihre beiden Schnittstellen wieder und die Zuordnung der Ports bleibt stabil.

Am falschen Ort messen

Meine erste Messung kam von einem Rechner im Heimnetz. Sie zeigte etwa 90 Mbit/s im Download und 40 Mbit/s im Upload und hat mich auf eine falsche Spur geführt, denn sie sagte nichts über die Anbindung des Servers. Messe zuerst direkt auf dem Proxmox-Host.

Speicher der Firewall-VM im Blick behalten

Die VM zeigte in Proxmox rund 96 Prozent belegten Arbeitsspeicher bei nur 5 GiB. Das ist bei Firewalls üblich, weil freier Speicher als Cache genutzt wird, trotzdem solltest du die Auslastung beobachten.

7. Dauerhaft überwachen statt einmal messen

Damit ein solches Problem nicht wieder monatelang unbemerkt bleibt, messe ich das Tempo seitdem automatisch. Ein Kubernetes-CronJob läuft alle 30 Minuten in einem Pod, lädt kleine Testdaten herunter und hoch und schickt die Werte an ein Pushgateway. Grafana zeigt daraus ein eigenes Dashboard. Der Kern ist eine kleine Shell-Funktion:

dl_one() {
  n=$1; url=$2; shift 2
  r=$(curl -s -o /dev/null -m 60 -w '%{speed_download} %{time_connect} %{http_code}' "$@" "$url")
  set -- $r
  echo "network_speed_download_bytes_per_second{target="$n"} $1" >> /tmp/metrics.txt
}

Wenn du eine Überwachung für deine Dienste suchst, lies auch Uptime Kuma mit Docker Compose einrichten und Kubernetes Monitoring mit Grafana und Prometheus.

8. Fazit

Wenn der Host schnell ist und alles hinter einer Firewall-VM langsam, schau dir zuerst das Kartenmodell der VM an. In meinem Fall haben zwei Einstellungen gereicht: VirtIO statt e1000 und firewall=0 an den Karten. Der Aufwand waren wenige Minuten Ausfall, der Gewinn der Faktor 17 bis 22. Entscheidend war, in Stufen zu messen und sich nicht auf einen einzelnen Wert zu verlassen.

Quellen

• Proxmox VE Wiki: Qemu/KVM Virtual Machines (Netzwerkgeräte)
• iperf3: Dokumentation

Häufige Fragen