Hallo zusammen,
ich habe seit dem Update von OPNsense 26.7.2 auf 26.7.3_11 ein sehr ungewöhnliches Verhalten in einer virtualisierten OPNsense-Installation unter Proxmox.
Da ich das Problem inzwischen relativ gut eingrenzen konnte, möchte ich den Fall hier dokumentieren und fragen, ob jemand ein ähnliches Verhalten beobachtet oder einen Hinweis zur Ursache hat.
Umgebung- Proxmox VE: 9.2.18
- OPNsense: 26.7.3_11 (amd64)
- CPU: 8 vCPU, CPU type "host"
- RAM: 16 GB
- Virtuelle Netzwerkkarten: 6 × e1000
- Netzwerk: vmbr0 bis vmbr5
- Virtueller Storage-Controller: VirtIO-SCSI
Die WAN-Schnittstelle in OPNsense ist
em0.
WAN-Konfiguration:
IP: 192.168.2.2
Gateway: 192.168.2.1
MAC: bc:24:11:75:66:97
Die MAC-Adresse stimmt dabei mit der entsprechenden virtuellen Netzwerkkarte in Proxmox überein.
1. Eingrenzung auf OPNsense 26.7.3Ich habe zunächst verschiedene Kombinationen getestet:
- Proxmox 9.2.9 + OPNsense 26.7.2 → funktioniert
- Proxmox 9.2.9 + OPNsense 26.7.3 → Problem
- Proxmox 9.2.18 + OPNsense 26.7.2 → funktioniert
- Proxmox 9.2.18 + OPNsense 26.7.3 → Problem
Damit ließ sich das ursprüngliche Problem für mich zunächst sehr deutlich auf OPNsense 26.7.3 bzw. den darin enthaltenen FreeBSD-Stand eingrenzen.
2. Ursprüngliches Storage-Problem mit OPNsense 26.7.3Beim ersten Start von OPNsense 26.7.3 trat zusätzlich ein Storage-Problem auf.
Unter anderem erschienen folgende Meldungen:
ata0: FAILURE - load data
ata0: setting up DMA failed
ZFS: WARNING: Pool 'zroot' has encountered an uncorrectable I/O failure and has been suspended.
Daraufhin habe ich über meinen Proxmox Backup Server (PBS) zunächst ein Backup von OPNsense 26.7.2 wiederhergestellt und anschließend den virtuellen Systemdatenträger von IDE auf VirtIO-SCSI umgestellt.
Der Datenträger wurde dabei nicht neu erstellt, sondern lediglich an einen anderen virtuellen Controller angebunden.
Mit OPNsense 26.7.2 und VirtIO-SCSI funktionierte das System anschließend problemlos.
3. Kontrolle unter OPNsense 26.7.2 mit VirtIO-SCSIUnter OPNsense 26.7.2 wurde der Datenträger korrekt als SCSI-/VirtIO-Datenträger erkannt:
camcontrol devlist
<QEMU HARDDISK 2.5+> ... (pass1,da0)
Auch ZFS war vollständig in Ordnung:
state: ONLINE
da0p4 ONLINE
errors: No known data errors
Damit war für mich zunächst klar, dass der Wechsel von IDE auf VirtIO-SCSI das ursprüngliche Storage-Problem behoben hatte bzw. zumindest der Storage-Pfad damit stabil funktionierte.
4. Upgrade auf OPNsense 26.7.3_11Anschließend habe ich die laufende und funktionierende OPNsense-Installation von 26.7.2 auf
26.7.3_11 aktualisiert.
Das ursprüngliche ZFS-/Storage-Problem trat mit VirtIO-SCSI nicht mehr auf.
Der Datenträger blieb online und ZFS meldete weiterhin keine Fehler.
Dafür trat jetzt ein anderes, sehr gravierendes Problem auf:
Das Netzwerk wurde extrem instabil und es war keine Internetseite mehr erreichbar.Zusätzlich wurde die WebGUI extrem langsam. Seiten benötigen teilweise sehr lange zum Laden oder schlagen gelegentlich komplett fehl.
Auf der Konsole erschienen außerdem weiterhin Meldungen wie:
ata1: FAILURE - load data
ata1: setting up DMA failed
Da unter 26.7.2 der eigentliche Systemdatenträger als
da0 über VirtIO-SCSI erkannt wurde, vermute ich, dass sich
ata1 auf das virtuelle CD-ROM-Gerät bezieht.
5. Netzwerk grundsätzlich vorhandenDie WAN-Schnittstelle
em0 war aktiv und korrekt konfiguriert:
IPv4: 192.168.2.2
Gateway: 192.168.2.1
Die Interface-Counter zeigten keine offensichtlichen Fehler:
Ipkts: 88203
Ierrs: 0
Opkts: 68583
Oerrs: 0
Auch ARP funktionierte:
? (192.168.2.1) at a8:f5:ac:c1:f0:f3 on em0 expires in 1186 seconds [ethernet]
Ein zusätzlicher Test mit tcpdump zeigte ebenfalls, dass die Kommunikation auf Layer 2 grundsätzlich funktioniert.
Der Gateway-Router konnte beispielsweise ARP-Anfragen an OPNsense senden und OPNsense antwortete mit der korrekten MAC-Adresse:
ARP, Request who-has 192.168.2.2 tell 192.168.2.1
ARP, Reply 192.168.2.2 is-at bc:24:11:75:66:97
Auch ICMP-Pakete wurden über
em0 tatsächlich ausgesendet:
192.168.2.2 > 192.168.2.1: ICMP echo request
Allerdings kamen die Antworten teilweise nicht zurück.
6. Entscheidender Test: PFDann habe ich einen sehr interessanten A/B-Test durchgeführt.
Mit aktiviertem PF trat das Problem auf.
Ich habe PF testweise deaktiviert:
pfctl -d
Unmittelbar danach war die Verbindung stabil.
Gateway:
ping 192.168.2.1
0.0% packet loss
Internet:
ping 1.1.1.1
0.0% packet loss
Und vor allem:
Internetseiten waren sofort wieder erreichbar.Auch die WebGUI reagierte wieder deutlich schneller.
Anschließend habe ich PF wieder aktiviert:
pfctl -e
Danach kehrte das Problem wieder zurück.
Mit aktiviertem PF war der Paketverlust erneut vorhanden und die WebGUI wurde wieder sehr langsam.
7. PF-Live-ViewInteressant ist dabei, dass die betroffenen ICMP-Pakete nicht einfach als Block angezeigt wurden.
Für einen fehlgeschlagenen Ping zum Gateway zeigte die Live View beispielsweise:
Interface: Internet
Direction: Out
Protocol: ICMP
Source: 192.168.2.2
Destination: 192.168.2.1
Action: pass
Das Verhalten lässt sich daher für mich nicht einfach durch eine offensichtliche Firewall-Block-Regel erklären.
Auch eine Suche nach einer entsprechenden PF-State-Session zum Gateway ergab keine auffällige Session:
pfctl -ss | grep '192.168.2.1'
PF selbst war allerdings eindeutig aktiv und hatte eine größere Anzahl von States:
current entries 1538
searches 644702
inserts 63767
removals 62376
8. Weitere BeobachtungenMit aktiviertem PF konnte ich beispielsweise folgende Ergebnisse beobachten:
Ping Gateway:
teilweise 0 % Verlust
teilweise 100 % Verlust
Ping 1.1.1.1:
teilweise 100 % Verlust
teilweise 66,7 % Verlust
IPv6:
100 % Verlust
Das Verhalten ist also nicht vollständig deterministisch.
Ein Ping kann funktionieren und der unmittelbar danach ausgeführte Ping kann vollständig ausfallen.
Mit deaktiviertem PF ist die Verbindung dagegen stabil.
9. Was ich inzwischen ausschließen bzw. eingrenzen konnte- Proxmox 9.2.18 als alleinige Ursache → eher unwahrscheinlich, da OPNsense 26.7.2 auf demselben Proxmox problemlos funktioniert.
- Defekter virtueller Systemdatenträger → eher unwahrscheinlich, da derselbe Datenträger mit VirtIO-SCSI unter 26.7.2 problemlos läuft und ZFS ONLINE meldet.
- Grundlegendes L2-/ARP-Problem → eher unwahrscheinlich, da ARP funktioniert und die MAC-Adressen korrekt sind.
- Physischer Netzwerkfehler → ebenfalls eher unwahrscheinlich, da OPNsense 26.7.2 mit identischer virtueller Netzwerkkonfiguration problemlos funktioniert.
- Eine einfache PF-Block-Regel → bisher nicht ersichtlich; die betroffenen ICMP-Pakete werden in der Live View teilweise ausdrücklich als pass angezeigt.
10. Aktuelle VermutungAktuell deutet für mich sehr viel darauf hin, dass das Problem mit Änderungen in OPNsense 26.7.x bzw. FreeBSD 15.1 und insbesondere mit dem PF-/Forwarding-/Network-Stack zusammenhängen könnte.
Besonders auffällig ist:
QuoteMit OPNsense 26.7.2 funktioniert die identische virtuelle Maschine unter Proxmox 9.2.18 problemlos.
Nach dem Upgrade auf OPNsense 26.7.3_11 tritt der Fehler auf.
Wenn PF deaktiviert wird, funktioniert das Netzwerk sofort wieder stabil.
Wird PF wieder aktiviert, tritt das Problem erneut auf.
Ich möchte allerdings ausdrücklich nicht behaupten, dass damit bereits die konkrete Ursache gefunden ist. Es könnte sich ebenso um einen anderen Fehler im Zusammenspiel von PF, dem Netzwerk-Stack und der Virtualisierung handeln.
11. Aktueller StandFür den produktiven Betrieb bin ich deshalb zunächst wieder auf OPNsense 26.7.2 zurückgegangen.
Dort läuft die VM unter Proxmox 9.2.18 mit VirtIO-SCSI wieder stabil.
Fragen an die CommunityHat jemand ein ähnliches Verhalten mit OPNsense 26.7.3 bzw. 26.7.3_11 unter Proxmox beobachtet?
Insbesondere interessieren mich folgende Punkte:
- Ist ein ähnliches Verhalten mit Paketverlust bei aktiviertem PF bekannt?
- Gibt es bekannte Probleme mit PF bzw. dem Forwarding unter FreeBSD 15.1 in dieser OPNsense-Version?
- Könnte die Meldung ata1: FAILURE - load data / setting up DMA failed trotz funktionierendem VirtIO-SCSI-Systemdatenträger relevant sein?
- Gibt es weitere sinnvolle PF-/Kernel-Diagnosen, mit denen sich der Fehler genauer eingrenzen lässt?
- Gibt es bekannte Workarounds für dieses Verhalten unter Proxmox/KVM?
Vielen Dank für jeden Hinweis!
Toby
Ich kann dazu nur sagen, dass ich grundsätzlich nicht mit "Emulationen" wie ATA oder E1000 arbeite, da bei dieser Übersetzungsschicht immer Probleme auftreten können - insbesondere, wenn sich wie hier mit dem Update auch der FreeBSD-Kernelstand ändert, obwohl FreeBSD 15.1 bereits mit 26.7.2 aktiv war. Virtio ist da meist die bessere Wahl, da dies eine für Virtualisierung optimierte Schicht ist.
Bitte entferne erst einmal die Legacy-Emulation aus dem Versuchsaufbau. Der ATA-Fehler ist vermutlich nur Dein emuliertes CD-ROM.
Das vorausgeschickt funktionieren meine so eingerichteten OpnSensen unter PVE jeweils in der aktuellsten Variante einwandfrei.
Siehe dazu insbesondere: https://forum.opnsense.org/index.php?topic=44159.0