Performante Pfsense/OPNSense Hardware gesucht

[g0nZo89]

Bin auch gespannt, werde unterschiedliche VPN Clients testen und ggf. IPSec nutzen. Muss kein OpenVPN sein.
Muss eher gucken, ob ich noch ein Modem und ggf. einen Switch brauche, oder ob ich die VLANs auch mit dem Gerät realisieren kann.
Bin auch gespannt ob das Wifi besser ist, als das vom aktuelle Speedport V724w. Aber das heißt dann work in Progress, finde kaum Infos oder Suche an der falschen Stelle.
Für den Preis + WLAN Modul, Gehäuse usw. musste ich zuschlagen. Da hätte ich keinen S920 oder T620 bekommen.

 

[p4n0]

Welche Software soll denn auf dem Teil laufen?
Das wird ja immer spannender, vor allem wenn's noch WLAN machen soll.
+ VPN > 100mbit + Inter-VLAN-Routing.

Berichte mal wie schnell das Ding nen Liter Wasser aufkochen kann.

 

[Gen8 Runner]

Bin auch gespannt, werde unterschiedliche VPN Clients testen und ggf. IPSec nutzen. Muss kein OpenVPN sein.
Muss eher gucken, ob ich noch ein Modem und ggf. einen Switch brauche, oder ob ich die VLANs auch mit dem Gerät realisieren kann.
Bin auch gespannt ob das Wifi besser ist, als das vom aktuelle Speedport V724w. Aber das heißt dann work in Progress, finde kaum Infos oder Suche an der falschen Stelle.
Für den Preis + WLAN Modul, Gehäuse usw. musste ich zuschlagen. Da hätte ich keinen S920 oder T620 bekommen.

Uff. Ich vermute, dass in das APU eine Mini-PCIe Karte verbaut wurde als "AP"?
Versuch macht klug, aber ich befürchte, dass das nen Schuss in den Ofen ist. Wenige Clients (1,2, evtl. auch 5 OHNE große Last) wird das Ding handlen können. Aber darüber hinaus wird es wahrscheinlich kriminell, da diese Karten eben nicht als AP designt sind.

Ich hatte damals auch die Idee in meinen Server ne WIFI PCIe Karte reinzuklatschen und diese als WLAN AP zu nutzen für PFSense, da wurde aber von allen Seiten von abgeraten. So zumindest mein letzter Kenntnissstand. Aber probier es. Bin auch gespannt auf Ergebnisse (nicht um nachtreten zu wollen, sondern man lernt nie aus).

 

[g0nZo89]

Hallo und guten Morgen, ja für mich auch ein Feldversuch. Ich kann mir kaum vorstellen, dass der Speedport eine gute Performance abliefert.
Alternative ist und bleibt ja, Speedport für WLAN und Firewall als "Firewall", dann ist das WLAN Modul eben nice to have und nicht aktiv.

Wie sich das realisieren lässt, dazu muss ich auch erstmal recherchieren. Wenn hier jemand einen Impuls hat, sehr gerne.

Beitrag automatisch zusammengeführt: 25.02.2021

Welche Software soll denn auf dem Teil laufen?
Das wird ja immer spannender, vor allem wenn's noch WLAN machen soll.
+ VPN > 100mbit + Inter-VLAN-Routing.

Berichte mal wie schnell das Ding nen Liter Wasser aufkochen kann.

Ich glaube es kann kein Wasser kochen, zumindest war diese Funktion im Datenblatt nicht beschrieben.
Ich hatte gehofft ich installiere die Firewall und finde dort ein WLAN Feature, soweit bin ich noch nicht.

Uff. Ich vermute, dass in das APU eine Mini-PCIe Karte verbaut wurde als "AP"?
Versuch macht klug, aber ich befürchte, dass das nen Schuss in den Ofen ist. Wenige Clients (1,2, evtl. auch 5 OHNE große Last) wird das Ding handlen können. Aber darüber hinaus wird es wahrscheinlich kriminell, da diese Karten eben nicht als AP designt sind.

Ich hatte damals auch die Idee in meinen Server ne WIFI PCIe Karte reinzuklatschen und diese als WLAN AP zu nutzen für PFSense, da wurde aber von allen Seiten von abgeraten. So zumindest mein letzter Kenntnissstand. Aber probier es. Bin auch gespannt auf Ergebnisse (nicht um nachtreten zu wollen, sondern man lernt nie aus).

Leider habe ich die genauen HW Specs nicht, sobald das Gerät da ist kann ich mehr dazu sagen. Ich vermute auch eine PCIe Karte, vllt die Intel i2xx.

Dann lieber einen AP gebridged oder den Speedport weiterlaufen lassen, hm.
Es soll die OPNSense werden.

 

[aftours]

Würde mich auch interessieren, wie deine performance so ist.

Hab selber auch eine apu2c4 relativ günstig bekommen bei Kleinanzeigen und warte darauf.

 

[XTaZY]

Es ist vielleicht ein bisschen Offtopic, aber hat Jemand Erfahrungen bzgl. OPNsense und dem Fujitsu Futro S920 ?
Mal abgesehen von VPN, kommt der Thin-Client mit DPI und IPS zurecht ?

 

[maxblank]

Damit zu recht kommen generell wird er. Die Frage wird sein, was der Prozessor, wahrscheinlich der AMD gx-415ga, schafft und was entsprechend an Durchsatz rauskommt. Wie viele Anwender bzw. Geräte müssen verwaltet werden? Wie ist die Geschwindigkeit von deinem Internet bzw. Netzwerk?

 

[XTaZY]

Ja ist der GX-415GA.
Aktuell sind es ca. 20 Clients, die hin und wieder mal ein bisschen Last ausüben.
500mbit -> später dann 1Gbit WAN

Hat der Fujitsu Futro S920 eigentlich eine PCIe 3.0 Schnittstelle und wieviel elektrische Lanes hängen da dran ?

 

[Mo3Jo3]

Kein Multithreading bei OpenVPN ist wirklich purer Anachronismus. Was nützt die beste (embedded) CPU mit massig Cores wenn eh nur einer genutzt wird? Lächerlich im Jahr 2019.

das war mal

Further, OpenVPN 3 is multi-thread capable and integrates with ASIO for all asynchronous processing and socket handling.

https://community.openvpn.net/openvpn/wiki/RoadMap

 

[XTaZY]

Ja ist der GX-415GA.
Aktuell sind es ca. 20 Clients, die hin und wieder mal ein bisschen Last ausüben.
500mbit -> später dann 1Gbit WAN

Hat der Fujitsu Futro S920 eigentlich eine PCIe 3.0 Schnittstelle und wieviel elektrische Lanes hängen da dran ?

Sind 4x elektrische Lanes, ich denke mal PCIe 2.0.

Hab mir jetzt mal einen für 50 € bei eBay geschossen und werd es einfach mal testen,
Ich denke 1Gbit mit aktivem IPS wird der Knecht leider nicht packen.

 

[Mo3Jo3]

Aktuelle Version von OVPN in der Community Edition ist 2.5.1.

Oha...... V3 scheint ja dann seit zwei Jahren in der Entwicklung. Benutze die integrierte Version in meiner Syno, wusste daher gar nicht genau welche Revision das ist.

Tutorial: Learn to Install and Control the OpenVPN 3 Client

This tutorial shows how to install the OpenVPN 3 client on various Linux distributions. In addition, commands to control the client are documented.

openvpn.net

 

[Mo3Jo3]

hat sich erledigt

 

[Elkarlo]

Ich hatte den Thread Ende 2020 entdeckt und wir hatten Beruflich die PFSense professionell eingesetzt, zu dem Zeitpunkt APU3D4. (3 Nic Ports 4GB Ram)

Ein paar Informationen:
Der Durchsatz lässt sich tatsächlich auch in der Wildbahn mit der Pfsense 2.4.4 erreichen wenn man den BSD Treiber von der Intel NIC Freischaltet.
Ab der Pfsense 2.5 braucht man das nicht mehr. Mit der neuen Firmware ab 4.10.0.1 ist der Turbo freigeschaltet, den man auch noch aktivieren musste, aktueller Stand ist 4.16.0.6
Also Pfsense aktuell auf 2.5.2+ bringen und die Firmware updaten dann lässt sich der Durchsatz ohne Verrenkungen erreichen.
Der Trick liegt darin das die Netzwerkkarte die Arbeit macht und nicht die CPU, das heißt aber auch: Mehr als AES 256 ist nicht drinn.
Beim Pfsense kann man die Hardware Entschlüsselung über System-> Advanced-> Misc -> Cryptographic&Thermal Hardware aktivieren.

Pfsense basiert auf BSD, das heißt das Einem Task eine CPU zugeordnet wird, also kein Sharing betrieben. Daher ist gerade die APU3D4 und die APU4D4 eine sehr gute Firewall:
NIC1&2&3&4 werden CPU 0&1&2&3 zugeordnet, da gibt es kein springen, aber auch kein Lasten ausgleich, daher ist die aktuelle Firmware auch wichtig.
Der Nachteil ist: Wenn CPU2 dicht ist, bremst es NiC3 aus. Der Vorteil: Ein Speicherseiten Angriff wie bei Spectre oder Meltdown, wovon diese CPU eh kaum betroffen ist,
ist aus Betriebssystemarchitektur heraus nicht möglich.

Ich habe wie gesagt nur Erfahrungen mit den 4GB Dingern gesammelt und kann sagen das OpenVPN, Firewall, Pfblocker(Pihole), Zabbix Agent, Zabbix-Proxy und Routing mit guten Ergebnissen
mit einem BSD OS auf einer APU3/4 mit 4GB Ram funktionieren.
Das Gerät geht selten in der CPU Auslastung hoch (über 20% meistens 5-6%). Wenn alles richtig aktualisiert wurde und die Rechenarbeiten den ASIC zugeschoben werden. Das funktioniert ohne Commandozeile
bei PFsense zb erst ab der 2.5.0

Die Pfsense werden zur Vernetzung und Management von 12 Standorten eingesetzt, wo zur Fernwartung man sich auf die Pfsense schaltet. Geringer Stromverbrauch und sichere Struktur
mit guter Performance war Vorraussetzung. Und es ist ein Gerät das man einmal einrichtet und laufen lässt.

Persönlich setze ich eine APU4D4 ein und habe aus Neugier nochmal vorbeigeschaut, ich habe sie zu weihnachten aufgesetzt und habe zuhause nen Loadbalancing der GF und Kabelleitung gemacht mit 2Gbit Bündelung ins Heimnetz. Packt es auch.

Wireless unter BSD bitte ganz schnell vergessen.

Immer daran denken das ein ASIC, gerade ein Crypto ASIC immer 4-10x so effizient ist wie ein general purpose Prozessor.

Das war schon vor im letzten Jahrtausend so, das es Netzwerkkarten und Netzwerkadapter gab. Die einen haben sämtliche Daten komplett aufbereitet und den Datenstrom direkt in die Northbridge gegeben und mussten nur noch in den Speicher geschoben werden, die anderen haben das komplette Netzwerkpaket an die CPU gegeben und die musste es verarbeiten. Das hat teilweise mal ohne weiteres 30-40% Last ausgemacht auf einem 500mhz Rechner. Ich rede mit dir Realtek RTL8139 100mbit Transfer und CPU blockiert. Während eine 3com Karte die Firewall, das Routing etc in ihren Speicher geladen hat und die RTL8139 gleich als 2ten Port sich angemeldet hat und die CPU dann gar nichts zu tuen hatte. (Fli4l projekte)
Die RTL8139 Karten waren damals nur so weit verbreitet weil sie schlicht und ergreifend 50% von den Via Rhine Chip gekostet haben bzw 20% von Intel und 3com. Dafür konnten sie aber auch nichts.

 

[asche77]

Da scheint mir einige Fehlinformation drin zu stecken:

Der Trick liegt darin das die Netzwerkkarte die Arbeit macht und nicht die CPU, das heißt aber auch: Mehr als AES 256 ist nicht drinn.
Beim Pfsense kann man die Hardware Entschlüsselung über System-> Advanced-> Misc -> Cryptographic&Thermal Hardware aktivieren.

Das schaltet m.E. die CPU Unterstützung ein (AES-NI), das hat mit der NIC nichts zu tun.

NICs bringen diverse Beschleunigungsfunktionen mit, die schaltet man m.W. aber über tunables ein und nicht über die o.g. Funktion.

Kryptographie Unterstützung bei den Intel NICs der APU2 (i210AT/i211AT) wäre mir neu.

Der Vorteil: Ein Speicherseiten Angriff wie bei Spectre oder Meltdown, wovon diese CPU eh kaum betroffen ist,
ist aus Betriebssystemarchitektur heraus nicht möglich.

Auch das stimmt so m.E. nicht. Richtig ist, dass eine Reihe der Angriffe auf SMT (a.k.a. HyperThreading) basieren und daher bei einer 4C4T CPU wie hier nicht relevant sein dürften.

Andere Angriffe auf Nachbar-CPUS / Threads basieren aber nicht auf SMT basieren (zB Spectre, das branch prediction missbraucht: https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/spectre.html).

Das hat aber nichts mit der Frage des "CPU-binding" zu tun (das kann man I.Ü. auch umstellen). CPU binding schützt nicht vor Seitenkanal Angriffen. Es betrifft v.a. Performance und Vermeidung von Race conditions.

 

[Elkarlo]

Da scheint mir einige Fehlinformation drin zu stecken:

Das schaltet m.E. die CPU Unterstützung ein (AES-NI), das hat mit der NIC nichts zu tun.

NICs bringen diverse Beschleunigungsfunktionen mit, die schaltet man m.W. aber über tunables ein und nicht über die o.g. Funktion.

Kryptographie Unterstützung bei den Intel NICs der APU2 (i210AT/i211AT) wäre mir neu.


Auch das stimmt so m.E. nicht. Richtig ist, dass eine Reihe der Angriffe auf SMT (a.k.a. HyperThreading) basieren und daher bei einer 4C4T CPU wie hier nicht relevant sein dürften.

Andere Angriffe auf Nachbar-CPUS / Threads basieren aber nicht auf SMT basieren (zB Spectre, das branch prediction missbraucht: https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/spectre.html).

Das hat aber nichts mit der Frage des "CPU-binding" zu tun (das kann man I.Ü. auch umstellen). CPU binding schützt nicht vor Seitenkanal Angriffen. Es betrifft v.a. Performance und Vermeidung von Race conditions.

AES-NI musste über die Netzwerkkarte aktiviert werden, nicht über die CPU in diesen Fall.
Man musste es beim 2.4.4 das AES-NI im Netzwerkkartentreiber aktivieren, ich habe es bei allen 12 händisch machen müssen und 3 Monate später kam das 2.5.0.
Daher meine Fehleinschätzung, es stimmt das es ein spezieller Cryptbereich (ASIC-NI) in der CPU ist, auch bei AMD,
aber bei einem BSD musste man die Intel-Lizenz bestätigen und das ging halt nur über den Netzwerkkartentreiber.
Da es eine Intel Lizenz ist und ein AMD Prozessor. Es war auch nur eine Bestätigung das man die Lizenz von Intel akzeptiert,
dann wurden die Queue's auf der NIC freigeschaltet und AES aktiviert, was 30% Performance auf der NIC brachte und die Last bei OpenVNP massiv senkte.
Ab Pfsense 2.5.0 ist es automatisch.
Habe es nochmal nachgelesen, für mich saß es halt in der NIC, da es übern NIC Treiber bestätigt werden musste, Intel will auch Geld verdienen.


Zum zweiten:

Aus dem Link:

2. A user process attacking another user process​

A malicious user process can try to attack another user process, either via a context switch on the same hardware thread, or from the sibling hyperthread sharing a physical processor core on simultaneous multi-threading (SMT) system.

Dagegen hilft genau CPU-Binding, einen Context switch auf dem gleichen hardware Thread. Dadurch das man gebunden ist zb bei einer 4C4T kann man wenn man auf Core 0 ist nicht auf die Threads in Core 1,2,3 zugreifen. Während bei einem Distributed System wie zb Linux man mit einem Thread auf allen CPU Kernen irgendwann ist, oder man nur warten muss bis der Thread vorbeiwandert. Das ist der Vorteil vom CPU-Binding.

SMT hat nichts mit Spectre zu tuen, es waren ja auch C2D und die ganzen iCore5 betroffen. Alles Non SMT Prozessoren.

 

[sch4kal]

aber bei einem BSD musste man die Intel-Lizenz bestätigen und das ging halt nur über den Netzwerkkartentreiber.
Da es eine Intel Lizenz ist und ein AMD Prozessor. Es war auch nur eine Bestätigung das man die Lizenz von Intel akzeptiert,

Ich hatte selber eine APU 2C4 hier, ebenfalls mit AMD Geode CPU und Intel NICs, da musste ich bei 2.4.4 gar nix bestätigen. Oder meinst du die Netgate Lizenz ?
Denn die muss man immer bestätigen, vollkommen gleiche welches CPU/NIC-Gespann verbaut wurde.

 

[Elkarlo]

Ich hatte selber eine APU 2C4 hier, ebenfalls mit AMD Geode CPU und Intel NICs, da musste ich bei 2.4.4 gar nix bestätigen. Oder meinst du die Netgate Lizenz ?
Denn die muss man immer bestätigen, vollkommen gleiche welches CPU/NIC-Gespann verbaut wurde.

Musste man nicht, konnte man aber wenn man alle Fähigkeiten freischalten wollte:

Aus einem Guide

These settings are the change between 2.4.4 and 2.4.5. Background for these settings: https://redmine.pfsense.org/issues/10465


Now we need to edit some settings from the shell. You can SSH to the box or connect with the serial cable.
To get the full gigabit, edit /boot/loader.conf.local (you may need to create it if it doesn't exist) and insert the following settings:

# agree with Intel license terms
legal.intel_igb.license_ack="1"

# this is the magic. If you don't set this, queues won't be utilized properly
# allow multiple processes to processing incoming traffic
hw.igb.rx_process_limit="-1"
hw.igb.tx_process_limit="-1"

 

[asche77]

Das hat aber nichts mit Verschlüsselung / AES zu tun (und das license_ack ist mit der Umstellung von "igb" auf "em" Treiber mW auch hinfällig).

Queues, RSS, MSI-X zu aktivieren hilft der Performance unabhängig von den crypto-Einstellungen.

Und auch bei CPU binding/pinning der pf-threads laufen unzählige andere Prozesse auf den cores, so dass ich da nicht wirklich den Schutz gegen CPU-Sicherheitslücken wie Spectre sehe.

 

[27k1]

@Elkarlo: Den Security-Aspekt hatte ich nicht auf dem Schirm.
Ich nutze IPFire, das auf Linux basiert. Wollte ursprünglich OPNSense nutzen, hatte aber IPFire erstmal installiert und bin dabei hängen geblieben. Mit den Einschränkungen, die wohl in IPFire 3.x wegfallen (wenn das irgendwann mal fertig sein sollte), kann ich leben bzw. habe die für meine bisherigen Zwecke ziemlich gut umschifft... .

IPFire soll deutlich schneller als *SENSE sein. Ich habe es nicht getestet bzw. verglichen aber schon mehrfach gelesen (u.a. auf der Seite teklager.se irgendwo (finde es gerade nicht) und in diversen Forenpostings), dass dazwischen fast schon Welten liegen sollen (insbesondere bei relativ schwacher Hardware und schneller Internetanbindung). Und seit dem ich das gelesen habe, hat man bei IPFire noch weiter an der Performance gedreht bzw. ist weiter dran vieles zu optimieren, so dass es noch schneller sein dürfte als in den damaligen Aussagen. Hinzu kommt wahrscheinlich noch bald Cake für QoS (derzeit noch fq_codel - es sei denn man fummelt selber daran rum).

Bin auch deswegen bei IPFire geblieben, da ich somit noch Luft für Proxy und IPS auf meinem System habe. Bei *sense würde das ggf. anders aussehen.

Dieser angebliche Perfomancevorsprung kommt wohl in erster Linie durch den Punkt zustande, dass unter Linux die Netzwerkgeschichten im Gegensatz zu BSD wohl weitestgehend multithreading sind (so habe ich es mal gelesen). Aus deinem Post: "Pfsense basiert auf BSD, das heißt das Einem Task eine CPU zugeordnet wird, also kein Sharing betrieben."
Dass dies ggf. Auswirkungen auf die Security aber haben kann, hatte ich nicht (wie schon geschrieben) auf dem Schirm.
Allerdings Zitat asche77: "Und auch bei CPU binding/pinning der pf-threads laufen unzählige andere Prozesse auf den cores, so dass ich da nicht wirklich den Schutz gegen CPU-Sicherheitslücken wie Spectre sehe."

Edit:

• "BSD also limits the maximum throughput per connection. Single connection on OPNSense will not utilize full capacity of multi-core CPU. (this is often not important unless you have a gigabit internet connection)"
• IPFIRE: "It utilized all CPU cores, making it very fast on multi-core CPUs"

Best free Linux Router and firewall software 2023 (4 recommendations)

Best Free Linux and BSD router and firewall distribution 2023. Best Open Source software for router appliance.

teklager.se

(das ist aber nicht der Link zu der obigen Aussage).

 

[asche77]

Ohne das gemessen zu haben, ist es auch meine Beobachtung, dass Linux-basierte firewall/router (openWRT) schneller als die BSD-basierten *senses arbeiten.

Wobei performance mässig openWRT leicht vor ipfire liegen könnte (v.a. wegen SQM mit layer_of_cake), aber eben (auf x86) etwas mühsamer zu installieren, aktualisieren und administrieren ist als ipfire.

Früher habe ich lange openWRT genutzt, bin aber o.g. leid und daher zu *Sense gewechselt.

 

[27k1]

Ohne das gemessen zu haben, ist es auch meine Beobachtung, dass Linux-basierte firewall/router (openWRT) schneller als die BSD-basierten *senses arbeiten.

Es scheint ein gutes Stück schneller zu sein. Inwieweit bzw. ob man das merkt, hängt dann von den Rahmenbedingungen ab. Aber man kann es je nachdem wie die sind wohl recht gut merken.

Wobei performance mässig openWRT leicht vor ipfire liegen könnte (v.a. wegen SQM mit layer_of_cake),

Cake ist ja im Linux-Kernel. Seitdem man den aktuellen Kernel in der IPFire hat, ist es im Prinzip da. Man müsste halt selber Hand anlegen. Aber man ist da offenbar dran es auch offiziell zu bringen.
https://wiki.ipfire.org/devel/telco/2022-01-03 bzw. https://patchwork.ipfire.org/project/ipfire/list/?series=2451

Die FQ_Codel Implementierung von IPFire soll sehr gut sein. Aber Cake ist halt noch mal besser.

Ansonsten muss man auch achten was man vergleicht. Ein OpenWRT out-of-the-box kommt anderes als ein IPFire daher.

aber eben (auf x86) etwas mühsamer zu installieren, aktualisieren und administrieren ist als ipfire.

Ja, das ist ein Haken. Und alle zusätzlichen Pakete muss man bei einem Update wohl neu einspielen.
Ich habe OpenWRT auf den AccessPoints (Ubiquiti) und einem EdgeRouter. Nutze die aber nur als dumme AP bzw. besseren Switch.

Früher habe ich lange openWRT genutzt, bin aber o.g. leid und daher zu *Sense gewechselt.

*Sense habe ich selber noch nicht wirklich verwendet.
IPFire ist IMHO eine ziemlich gute Wahl, sofern einem das Konzept (insbesondere hinsichtlich Zonen und VLANs) nicht zu sehr einschränkt (mit IPFire v3 fallen wohl diese Einschränkungen großteils aber da deren Team so klein ist fehlt es an Ressourcen und das wird daher noch dauern).

 

[27k1]

@Elkarlo:

How to fine-tune pfSense for 1Gbit throughput on APU2/APU3/APU4​

APU2 1Gbit throughput on pfSense (configuration instructions)

How to configure pfSense to route full Gigabit on APU2 (tutorial).

teklager.se

OPNSense performance optimization for gigabit speed​

OPNsense performance optimization

Optimization of OPNsense performance on low power devices (APU2, APU3, APU4)

teklager.se

Anmerkung: Bei Hardware-Offloading könnte es sein, dass besseres QoS wie FQ_Codel (oder Cake => gibt es aber nicht für BSD) eingeschränkt oder gar nicht läuft.

 

[sch4kal]

Für ~100 Mbit/s VPN- und ~1 Gbit/s Routingdurchsatz taugt jede FOSS-Firewall. Dazu braucht man nicht zwingend IPFire.
OPNSense und pfSense kann man bis etwa 10 Gbit/s Firewalldurchsatz mit entsprechender Hardware nutzen, alles darüber verlangt nach spezielleren (und teureren) Lösungen.

 

[27k1]

Das ist so pauschal nicht richtig, zumindest wenn die CPU nicht so stark ist und man dies mit Hardware-offload umgehen kann (mit gegebenenfalls anderen Nachteilen). Siehe Tabelle im Link: https://teklager.se/en/knowledge-base/apu2-1-gigabit-throughput-pfsense/

Operating system	Single Connection	Multiple Connections
pfSense 2.4.5 (with tweaks)	750 Mbit/s	1 Gbit/s
pfSense 2.5.0 (no tweaks required)	590 Mbit/s	1 Gbit/s
OpenWRT	1 Gbit/s	1 Gbit/s

 

[sch4kal]

Ne APU2 hat aber auch einen uralten und langsamen AMD Geode Chip...das ist keine aktuelle Hardware. Jeder Celeron Dualcore ab Sandybridge reicht für Gigabit ivm den *senses locker aus.

 

[27k1]

Ne APU2 hat aber auch einen uralten und langsamen AMD Geode Chip...das ist keine aktuelle Hardware. Jeder Celeron Dualcore ab Sandybridge reicht für Gigabit ivm den *senses locker aus.

Habe auch schon Vergleiche gesehen (war u.a. im Heise-Forum), in denen ein J3160 (oft in Protectli drin) bzw. vergleichbare Systeme mit *sense gegenüber den Linux-Systemen mehr eingebrochen sind.
Wenn dann noch weitere Dienste wie IPS laufen sollen... .

Ich würde es am liebsten ausprobieren und mal gegenüberstellen. Zeit ist aber knapp für solche Experimente und meine Internetleitung muss funktionieren (2 x Home-Office).

 

[asche77]

Hardware-Offloading könnte es sein, dass besseres QoS wie FQ_Codel (oder Cake => gibt es aber nicht für BSD) eingeschränkt oder gar nicht läuft.

Hardware offloading soll man für die Firewall ohnehin deaktivieren (siehe Doku pfsense/Opnsense), damit "higher up on the stack" die Firewall bzw IDS/IPS die original Pakete prüfen kann.

 

[27k1]

Cake ist ja im Linux-Kernel. Seitdem man den aktuellen Kernel in der IPFire hat, ist es im Prinzip da. Man müsste halt selber Hand anlegen. Aber man ist da offenbar dran es auch offiziell zu bringen.
https://wiki.ipfire.org/devel/telco/2022-01-03 bzw. https://patchwork.ipfire.org/project/ipfire/list/?series=2451

Die FQ_Codel Implementierung von IPFire soll sehr gut sein. Aber Cake ist halt noch mal besser.

It is time to release another Core Update for IPFire. It comes with an improved Quality of Service based on CAKE and various bug fixes and a lot of package updates.

IPFire Blog

The IPFire Blog has the latest news from the IPFire Project about Development, Current Affairs, and many more interesting things.

blog.ipfire.org