Messages

Protectli.... Notfalls eine gute gebrauchte. Ich habe nun die zweite in Folge. Als Vorbereitung für Fibre... In meinem Fall eine 6630.


Ja, mich würde eine virtualisierte FW stören. Sogar sehr. Die Gründe dafür sind vielfältig. Hier einige davon.

SPOF - Single Point of Failure
Fällt der Proxmox-Host aus, fällt gleichzeitig die gesamte Firewall und damit das komplette Netzwerk aus.

Boot-Abhängigkeit
Ohne laufende Firewall kann der Hypervisor evtl. keine Updates, NTP, DNS oder Remotezugriff bekommen. Wartung wird komplizierter.

Fehlkonfiguration kann alles lahmlegen
Fehler in virtuellen Switches, Bridges oder VLANs können die Firewall sofort unerreichbar machen.

Sicherheitsrisiko durch Hypervisor
Wird der Hypervisor kompromittiert, ist auch die Firewall kompromittiert. Die Isolation ist schwächer als bei dedizierter Hardware.

Netzwerk-Komplexität steigt
Virtuelle NICs, Bridges und VLAN-Konfigurationen erhöhen die Fehlersuche und machen das Setup anfälliger.

Ressourcenkonkurrenz
Firewall teilt sich CPU/RAM/IO mit VMs -> unter Last kann Routing, VPN oder IDS/IPS langsamer werden.

Wartung verursacht Downtime
Neustart oder Update des Hypervisors unterbricht automatisch die Verbindungen.

Hallo allerseits,

schönes Thema. Dachte eigentlich auch die halten länger. Bin aber auch erst seit Ende 2023 mit NVMEs dabei.

Mir ist letztens meine System Disk 990 Pro 2TB gestorben. Die war in ~3 Jahren so gut wie unbenutzt... Da auf der Disk nur das OS war. TBW sozusagen fast "neu". Kühlung etc kann ich auch ausschließen. Steckt unter der Heatsink eines Aorus Master X670E. Also ein massiver Kühlblock

Bei meiner OPNsense fiel mir auch auf, dass eigentlich zu viel geschrieben wird. Das habe ich nun auf ein minimum reduziert.
=> RAM disk und logging auf extern

Code Select Expand

date && smartctl -a /dev/nvme0 | grep "Data Units Written" Sat Jun 21 10:37:21 CEST 2025 [b]Data Units Written: 30,577,050 [15.6 TB][/b]
date && smartctl -a /dev/nvme0 | grep "Data Units Written" Sun Mar 15 08:35:05 CET 2026 [b]Data Units Written: 31,413,488 [16.0 TB][/b]
Macht nach Adam Ries: ≈ 1.60 GB pro Tag
Einzige was ich auch noch ausgeknippst habe, war das logging von Suricata. Hatte dazu einen Thread hier aufgemacht und ebenfalls eine Github issue.

Wäre cool, wenn jemand Vergleichwerte beisteuern kann.


Edit: Nebenher heißt das Layer 8 / L8... Nix Iso.. Oder auch Fehler 40, oder halt DAU....
Ref: https://de.wikipedia.org/wiki/Layer_8

@Patrick
Die Aussage "IPv6 ist das Internet und IPv4 nur noch Altlast" klingt zwar schön pointiert, ist technisch aber ein bisschen zu grob mit der Axt formuliert. In der Praxis läuft das Internet nach wie vor überwiegend im Dual-Stack, also parallel über IPv4 und IPv6. Selbst große Anbieter liefern Inhalte fast immer über beide Protokolle aus, weil ein erheblicher Teil der Netze weiterhin nur IPv4 oder nur eingeschränktes IPv6 hat.

Auch die pauschale Aussage zur Performance ist so nicht haltbar. Weder das eine noch das andere Protokoll ist per se schneller. Unterschiede entstehen fast immer durch die Providerarchitektur. Etwa wenn IPv4 über CGNAT oder DS-Lite läuft und deshalb einen Umweg macht. Dann kann IPv6 tatsächlich niedrigere Latenzen haben. In Netzen mit nativen IPv4-Routen sieht das aber oft genauso schnell aus.

Kurz gesagt: IPv6 ist definitiv die Zukunft und man sollte es sinnvollerweise aktiv nutzen, wenn der Provider es sauber liefert. Aber IPv4 als "Legacy, das eigentlich schon vorbei ist" darzustellen, ist aktuell eher Wunschdenken als technische Realität. :p Das sagt mir auch mein WAN Simulator im Lab.

Und ja, ich fand IPv6 schon damals in den Cisco/PA/... Trainings+Certs sch..... ;) Nebenher war 1981 ein großartiges Jahr. Nicht nur wegen IPv4 *g*
*duck und wech*




Zum Thema:
Wenn du prüfen willst, ob es wirklich langsamer geworden ist, ein paar einfache Checks:

=> Ping vergleichen: ping -4 und ping -6 auf denselben Host, Latenz und Paketverlust vergleichen.

=> Traceroute getrennt testen: traceroute -4 / traceroute -6, um unterschiedliche Routingpfade zu sehen.

=> Browser DevTools (Network-Tab): DNS-Zeit, TLS-Handshake, TTFB und Gesamtladezeit vergleichen.

=> curl Timing: curl -4 und curl -6 mit Timing-Output (-w), um Connect- und Transferzeiten zu sehen.

=> tcpdump auf der Firewall: schauen, ob Retransmits, ungewöhnliche Delays oder Path-MTU-Probleme auftreten.

=> Wireshark am Client: TCP-Retransmissions, Handshake-Zeiten und mögliche Paketverluste analysieren.

=> iperf3 im eigenen Netz: Durchsatz zwischen Client und Firewall bzw. zwei Hosts prüfen.

Passt folgendes?

- Routing?
- NAT?
- Firewall Regeln?

Notfalls nen dump machen und ebenfalls in den Firewall logs schauen, ob etwas blocked wird.

Program 'OPNsense_Update_Check'
  status                       OK
  monitoring status            Waiting
  monitoring mode              active
  on reboot                    start
  last exit value              0
  last output                  NO_UPDATE: Current version: 26.1.3
  data collected               Thu, 05 Mar 2026 22:27:06

@iani Das ist keine FW Appliance, sondern in Mini-PC mit zwei NICs. Dazu auch noch mit nem Realtek Chipset. Leider ist es bei den meisten dieser Geräte so, dass man keine Ersatzteile bekommt.
In meinem Fall für den Mini-PC auf den mein Home Assistant läuft, durfte ich einen Ersatzlüfter aus China bestellen. Kostenpunkt mit Shipping 42,xx€

Ich hätte Dir auch noch ne FW4B für ~100€ anbieten können. Liegt bei mir nur noch rum.

Living and Learning. Oder Learning by Burning :D

Viel Spass && Erfolg

Für das Heimnetz bin ich persönlich auch ein Freund von Konsolidierung und Virtualisierung. So wenig Hardware wie möglich, nicht zuletzt wegen des Stromverbrauchs.

Mein gesamtes Heimnetz - Switch, GPON-ONT, WLAN-AP, OPNsense, File Server, mehrere RIPE Atlas Probes, LTE-Modem, USV, Freifunk, Smart Home Controller, Hue Bridge, DECT (bestimmt habe ich etwas vergessen) - habe ich mittlerweile auf 32 Watt gedrückt. Und da ist noch Luft nach unten, die nächste Optimierung ist schon geplant. :)

Aber ich stimme Patrick zu, dass man nicht zu viel auf einmal anfangen sollte. Gerade die Konstellation "keine Erfahrung mit OPNsense und keine Erfahrung mit Virtualisierung" sorgt bei vielen schnell für Frust.

Grüße
Maurice

Was die Effizent angeht, gebe ich Dir sicherlich recht.

Trotzdem sollte man meiner Meinung nach gerade bei einer Firewall dem KISS Prinzip folgen. Eine FW ist eine FW und sollte das auch bleiben, ohne jeglichen Overhead.

Meine 2 Cent ...

Lenovo m720q (i5-8500T, 32 GB RAM, SATA- und NVMe SSD) mit PCIe riser und Intel i350-T4 (https://ibb.co/TLdBRXw). OPNsense läuft virtualisiert unter Proxmox. Die Hardware taugt dann auch noch für weiter Spielereien mit PVE. Bezogen von AMSO bzw. dessen Shop bei eBay. Leider nicht mehr so günstig wie vor 2 Jahren.

Willst du, dass bei jeder Wartung an deinem Hypervisor das gesamte Internet weg ist? Das der Hypervisor braucht, um seine Updates (z.B.) herunterzuladen.

Bin mir gerade nicht sicher wobei das Internet öfter "weg" ist. Bei der Wartung von PVE oder bei Updates/Upgrades von OPNsense?

Wenn man kostenbewusst unterwegs ist, wird man sich dieses Teil sicherlich nicht kaufen...


Verlustleistung (TDP) 35 W
Konfigurierbare TDP-down 25 W
14nm...^

eher nicht...

Also mal meine zwei Cent zu dem Thema.


Protectli: Tolle Hardware und wirklich guter Support. Und ja, je nach Model schlagen die Hardwareseitig auch locker eine Deciso. Nein, dass soll kein Deciso gebashe werden. Einfach simple Fakten ;)

Fritzbox: Eine Fritzbox ist ein Consumer produkt. Bzw eine Eier legende Wollmilchsau. Ich hatte jahrelang eine 7590 und letzlich damit nur Probleme.

Für die Stabilität würde ich deutlich zu einem reinen Modem greifen und pppoe über die OPNsense aufbauen lassen. Warte selbst immer noch auf  Fibre... Allerdings tut mein Vigor 166 nun seit Jahren den Dienst. Das deutlich performanter und stabiler als die Fritzbox jemals war. Auch bezogen auf Gaming und den heiß begehrten niedrigen Latenzen.

Und wenn Du auch noch WLAN auslagern willst, kauf Dir einen gebrauchten Ubiquiti 6 LR und pack OpenWRT drauf. Kostenpunkt ~100€

Think about the order of your rules and what they cover.

I assume that this QFEED contains external IP addresses.

You allow everything what is not local in rule 2. When will any flow reach that rule exactly if it contains non RFC1918 addresses?

I did mention that the HOWTO does not cover any streaming from local. For that: I don't know your setup.

I have try to use this setup my sonos and unable to get it working

Ok.

@Mr.SmartEpants: You should really think about your QFEED rule. But hope you already realized it.

"I'm guessing I need to add a "Sonos pass" rule before the "block access to 'private' networks" rule? "

=> Indeed

A flow is the permitted connection path through the firewall, defined by source, destination, protocol and port. So for Sonos that includes the controller -> speaker TCP connections and the mDNS UDP 5353 traffic that must be able to pass (or be repeated) between the VLANs.

Show me your "LAN" rules.

1. Did you setup the mDNS Repeater correctly?
2. Are you sure the Aliases fit?
3. Sure that the "trusted" network has the correct flows opened? Maybe I was too unclear when talking about trusted network?


Edit: You could even remove the "Rule_1: SRC: Sonos_Speakers, DST: != Local_Networks, Protocol: TCP, Ports: Ports_Sonos_TCP" rule... Basically you already allow any device in the IOT Network to reach the Internet. But I guess you know what you're doing there?

Edit_2: != Local Networks refer to RFC1918
Ref: https://datatracker.ietf.org/doc/html/rfc1918

Based on the log you attached, there is no indication of a full system crash or kernel panic.

What the log clearly shows is:
- Repeated PPPoE link failures (LCP: no reply to echo requests, reconnect loops)
- Frequent WAN down / up cycles
- Continuous dhcp6c "Network is down" errors while the PPPoE interface is offline

Eventually a reboot (---<<BOOT>>---), which strongly suggests a manual reset or watchdog, not a spontaneous crash

This behavior is consistent with an unstable WAN / PPPoE connection or NIC driver issue, not with a WAN problem taking down the whole system. Normally even PPPoE reconnect loops do not stop LAN DHCP or the GUI.

If the box becomes unreachable (no GUI, no SSH, no LAN DHCP) while still replying to ping, likely causes are:
- NIC driver lockup
- Hardware issues (RAM, storage, PSU)
- High load or kernel deadlock triggered by repeated interface resets

In short:
The WAN failure itself is almost certainly not the root cause. The log points to WAN instability acting as a trigger, exposing an underlying system or hardware problem.

Suggestion: As you did not mention the hardware of the appliance. I would do a stress test with the machine. For instance I take this quite seriously,  therefore I test my machines full 24-72h via stress-ng and others like memtest+ etc...
I tested my Protectli 6600 the same way. Result was that it's extremely stable.  In other words "Rock Solid".  I know there are other views in this forum about Protectli, but I can tell only good things. Especially about the support.