Performance Probleme bei Speedtest

Started by Gafzgarrr, January 04, 2022, 10:57:31 AM

Previous topic - Next topic
Hallo Forum,

gleich vorab: ich habe dieses topic auch im Englischen Bereich erstellt, aber ich versuche es auch mal hier auf deutsch und werde die Lösung in beiden topics einstellen.

Ich habe seit längerem massive Speedprobleme bei Speedtests.
Meine Opnsense (APU Board 4d4) hängt direkt am Bridgemodem.
Dort bekomme ich meine gebuchten 200/8Mbit/s dauerhaft (immer +5% sogar).

Aber hinter der Firewall bekomme ich (in allen Sub-Netzen) nur 10-15Mbit/s Down. Uplink liegt immer voll an!
Ich habe schon alle möglichen Blocker wie suricata, ntopng und netflow abgeschalten. Leider ohne erfolg.

Ich habe auch die empfohlenen APU Hardware Verbesserungen von teklager.se durchgeführt. Auch ohne Verbesserung.

Interessant ist aber, wenn ich die Sense neu starte, bekomme ich nach dem reboot für ca. 5 - 10 Minuten den vollen speed.
Selbes gilt auch, wenn ich packet-filter kurz ab und wieder an schalte (kann nicht ganz abschalten, da sonnst kein NAT.
In der Überwachung konnte ich feststellen, dass wenn ich den vollen speed bekomme, der wert pf.search massiv nach oben geht.
Wenn ich speedtest mache und nur 10 Mibt bekomme, passiert dort gar nichts.

Jemand eine Idee?

Viele Grüße


January 04, 2022, 10:12:46 PM #1 Last Edit: January 04, 2022, 10:24:47 PM by Gafzgarrr
Okay, ich habe gesehen, dass ich unter Firewall/settings irgendwelche settings für Multi-WAN aktiv habe.
Das abzuschalten (da ich nur 1x WAN Gateway nutze) hat mich schon mal auf 30-50Mbit/s gebracht.

Die Einstellung MTU-size from ISP freigeben hatte mich kurz mal auf 70Mbit gebracht, ist aber nach 2-3 Minuten wieder auf 12 abgefallen.

Ich vermute irgendwas weiteres in den Firewall Settings, dass meine Verbindungen limitiert.

Ideen?

UODATE: falsche info: nach 15 Minuten ist wieder alles bei 12Mbit/s

also, ich persönlich würde die apu (ohne vpn bedarf) maximal an einer 100mbit/s leitung betrieben.
die performance ist schon sehr mager bei der kiste.
was genau dein problem sein kann, keine ahnung (hast du mal eine etwas potentere hardware getestet ob du da das gleiche problem hast)?
und lass auf alle fälle suricata weg.
Internet: Willy.tel Down: 1Gbit/s, UP: 250Mbit/s Glasfaser  |
Router/Firewall: pfSense+ 23.09  |
Hardware: Netgate 6100

Moin,
also ich nutze OPNsense auf einer uralten Atom D525-Hardware.
Aktiviert sind FW, Proxy, DNS-Blacklist, Netflow
Ich habe eine 100/40-Leitung und das kommt auch bei meinen Endgeräten an. Ich hatte das Teil mal an einer 250/50-Leitung und auch da gab es keine Probleme die Leistung in Netzt zu bringen.

Ich würde systematisch Stück für Stück vorgehen.
Also Config-Sichern und optimalerweise mit einer Neuinstallation der OPNsense anfangen. Erstmal Basic-Einrichtung mit minimalen Regelset und dann langsam herantasten, wo genau das Problem liegt.
BTW: Evtl. testweise mal einen Switch zwischen Bridge-Modem und WAN-Schnittstelle der APU4 hängen. Nicht, dass es hier ein Problem in der Netzwerkkommunikation APU/Bridge-Modem gibt.

Gruß
Dirk

Hi Dirk, danke für den Tipp.
Das mit dem switch hat leider nichts gebracht.

Nach einem erneuten reboot konnte ich mal wieder für 5 Minuten meine 200Mbit Down nutzen.
danach wieder nix mehr.

Irgendwas muss im Initialisierungsprozess dazu kommen, was stört.

Könnte es an den NATs liegen?
Oder kann mir jemad sagen, wie ich den Boot Prozess step-by-step verfolgen kann?
Oder ggf. welche Rule am meisen genutzt wird?

Ich möchte das neu-aufsetzten soweit wie möglich umgehen.

VG

Noch ein Update: ich habe jetzt festgestellt, dass ich 88% Block rate habe.
Das sind alles IPv6 ICMP packete.
Ich vermute die Mullen mir mein system voll!

Irgend eine Idee wie ich das verhindern kann?

so wie es aussieht bin ich selbst der verursacher?? oder kann das auch der Router vom ISP bzw. das Bridge Modem sein?
siehe Bild

Warum eine "block all IPv6" Regel? Schalt es doch einfach ganz ab.

Die Grundsatzdiskussion erspar ich uns jetzt, aber statt zu blocken, mach's doch aus.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: Gafzgarrr on January 04, 2022, 10:57:31 AM

Ich habe auch die empfohlenen APU Hardware Verbesserungen von teklager.se durchgeführt. Auch ohne Verbesserung.


Welche Hardware Verbesserung wäre das denn?

Ich habe selber ein APU board mit 3 NIC's an einem Vodafon Kabelanschluss mit 250 Mbit/s.
Die Vodafone Station ist im BridgeMode und ich bekomme hinter der Firewall am Client über LAN immer um 250-270 Mbit/s.

Die von Teklager vorgeschlagenen Verbesserungen wären die hier:
https://teklager.se/en/knowledge-base/opnsense-performance-optimization/

die "block all IPv6" Rule ist automatisch entstanden nachdem ich v6 unter Firewall/Einstellungen/Erweitert abgeschalten habe.
Wenn ich dort wieder an schalte, bekomme ich trotzdem die ganzen packete, nur halt auf "pass".
Ich werde hier vermutlich von meinem ISP mit v6 Broadcast zugemüllt.
Kann ich das irgendwie verhindern?

VG

Möglicherweise ist es das logging der Pakete, das Dir die Performance versaut. Du könntest versuchen, "Allow IPv6" wieder einzuschalten (das entfernt die Regel) und stattdessen eine Floating Rule einzurichten, die IPv6 sperrt (BLOCK) aber nichts loggt.

Außerdem stell sicher, dass Du wirklich auf allen Interfaces IPv6 auf "None" gestellt hast. Damit bist Du zumindest sicher, was unerwünschte Kommunikation angeht und wenn es Dir das Log nicht mehr voll müllt, bessert sich vielleicht die Performance. Ich kann mir nur schwer vorstellen, dass der Multicast-Kram so viel Bandbreite verbraucht. Wenn Dein ISP IPv6 liefert, dann ist das natürlich normal.

Was meinen letzten Beitrag angeht, muss ich mich korrigieren, sorry. Die Möglichkeit, IPv6 zur Laufzeit komplett "aus" zu machen, existiert in FreeBSD nicht mehr.

Also konfigurier mal wie von mir gerade skizziert. Außerdem würde ich gucken, wieviel Bandbreite das wirklich ist - einfach bei ansonsten "idle" Uplink gucken, was auf dem WAN so reinkommt. Wenn das tatsächlich messbar ist, dann mal den IPS treten ;)

Und: weshalb hast Du da ein Bridge-Interface und nicht nur das WAN? Die Performance der Bridge ist in FreeBSD < 13 notorisch "schlecht" - im Sinne von suboptimal - was man speziell bei kleinen Maschinen mit geringer Single-Core-Performance merkt. Auf unseren großen Hosting-Servern mit Xeon XY haben wir 100 Jails auf einer Bridge mit Gigabit, aber auf einem Apu wirst Du kein Gbit mit Bridge erreichen können. Ab FreeBSD 13 wird's dramatisch besser, da komplett neu geschrieben, ist aber für die kleine Box immer noch viel Overhead. Wenn Du ohne die Bridge auskommen kannst, dann solltest Du das tun.

Es sei denn, ich mißverstehe hier was - dazu bräuchte ich allerdings einen Netzwerk-Plan. Wenn Du die Bridge z.B. intern benutzt, um aus den 3 Ports deines Apu einen kleinen Switch zu bauen - mit dem Apu nicht zu empfehlen. Kauf einen Switch. Wirklich, jetzt ;)

Sorry, zwei Themen in einem Beitrag, ich hoffe es wurde nicht zu unübersichtlich. Ich würde erst mal das mit dem "drop ohne log" angehen und dann mal nach der Netztopologie schauen.

Gruß
Patrick
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Das mit der Bridge war ein fehler, die habe ich inzwischen wieder raus genommen (Wollte port-mirror bauen).

Deine Idee mit den Rules klingt gut, aber leider kann ich ICMPv6 nich blocken, da es eine Automatische Rule ist, die ich nicht überschreiben kann (siehe Bild).

Ich habe über ntopng jetzt mal die packte zählen lassen.
Das waren in 13 Stunden über 2Mio Packete mit 160Mbit.

Ich glaube auch nicht, dass es die Mbit sondern die Menge der Packete sind (wie bei DDos Atacke).

Okay, ich konnte mein Problem lösen, auch wenn ich nicht sicher bin woran es genau lag.

Um den Fehler einzugrenzen, hatte ich alle Plugins abgeschalten (suricata, ntopng, netflow).
Das brachte keine verbesserung.
Daraufhin habe ich die große Menge an ICMPv6 auf WAN bemerkt und das vermutet.
Leider lässt sich das NICHT abschalten.
Die Einträge werden immer geloggt, da entweder v6 disabeld --> dann kommt eine automatische floating rule mit log über alle v6 Blocks; oder v6 enabled --> dann kommt eine automatschische floating rule, die ICMPv6 loggt.

Nach einigem googeln habe ich das .php Script gefunden, wo die auto-rules erzeugt werden (/usr/local/etc/inc/filter.lib.inc) und habe die entsprechenden bereiche raus komentiert.

Siehe da, die ICMPv6 Rule ist weg.

Aber immernoch das Speedpoblem + neu: die automatische bolean v6 Rule auf WAN loggt jetzt  >:(

Aber jetzt nochmals alle Plugins abgeschalten und siehe da: jetzt ist suricata der Übeltäter.
Mit suricata bekomme ich zw. 60-70Mbit/s ohne 207Mbit/s.

Somit lasse ich jetzt die default ICMP rules weg, und suricata aus.

Viele Grüße --> GELÖST