Recent posts

#1

Hardware and Performance / Re: Suggestion for Bufferbloat...

Last post by Seimus - Today at 10:23:53 AM

If you implement/tune FQ_C properly for the wire it will reflect on wireless as well. But implementing/tune this while testing from WiFi seems to me a very bad idea. The Wireless has so many variables that can play into the latency just for the Wireless last mile.

I am having a lot of devices on wireless too (only one PC is wired, servers are wired, phones, laptops and other stuff is wireless), WiFi6, but my Wireless APs are specifically tuned to the environment I live in (I am speaking here about tweaking on the AP itself + lot of measurements on the wireless freq using scanners). A lot of those devices are TVs & PCs for IPTV, VOIP, live streams, even online gaming, basically all the good stuff that hates any jitter.

The way how I did implement/tune FQ_C was as described in the docs, while testing was running from the single wired PC on the network. When I was happy with the score, from the artificial tests, I did turn on a live stream and run speedtest to observe if that live stream will show any stutter. If it stutter was present, and it was constant (unbearable) I tuned the FQ_C again to mitigate the stutter.

My tuning went into the advanced section as well, that was mainly because when the docs were created I needed to know what it does, how it behaves and if it even works as it should. But usually, you really only need to configure it as per the docs + basic tuning (BW tuning increasing decreasing) to get positive results. Main tuning parameter is the BW. All other parameters default are set well out of the box except "limit", but to use "limit" you need to be at least on 25.7.8.

Regards,
S.

#2

German - Deutsch / Re: OpnSense 25.10_2 HA Cluste...

Last post by Patrick M. Hausen - Today at 10:22:10 AM

IPSec Tunnels die eingerichtet sind, werden sowohl auf der Master Node als auch auf der Backup Node aktiviert.

Wenn IPsec tatsächlich auf der VIP konfiguriert ist, wäre das ein Fehlverhalten. Wie ist IPsec eingerichtet? Mit der neuen Connections Methode oder eine alte Service-Konfiguration? Eventuell könnte das beim neuen Connections-Setup dann ein Fehler sein, müsste man einmal nachstellen.

Mit der neuen Connections Methode startet er die Tunnel auf beiden Nodes, wenn die Start Action auf "Start" steht. Das hatte ich in diesem Ticket bereits reklamiert:

https://github.com/opnsense/core/issues/9082

Der Workaround ist, ausschließlich "Trap" zu verwenden, also auch in den DPD und weiteren Actions.

Gruß
Patrick

#3

German - Deutsch / Re: Konfiguration der Rebind S...

Last post by JeGr - Today at 10:00:46 AM

Dann hast du nicht gelesen was ich geschrieben habe. Ich mache für alles "LAN net", den Rest sehe ich als "Default Block" Verstöße und die fallen auf, weil es sie nicht geben dürfte. Weniger Logspam und Logs gehen nicht im Rauschen unter, weil dann NUR Sachen gegen Default Block laufen, die im Netz nichts zu suchen haben. Alle legitimen (LAN net) werden durch die eigenen Regeln geblockt. Dadurch einfacher filterbar. Das war nicht das was du schreibst, darum meine Erklärung :)

Vereinfachtes Beispiel in Grafik: Erlaube diverse ICMPs, rejecte alles interne + reservierte IPs, erlaube Rest aka Internet. Ja könnte man kombinieren, nein mache
ich nicht (sonst kann man das Loggen für die Rejects nicht einfach an/ausschalten) :) Wenn jetzt einer deiner genannten Fälle kommt: falsche Source IP weil Bot, manuell vergeben, APIPA o.ä. -> wäre sofort ersichtlich in Firewall Logs weil als default block auftauchend. Wird aber nicht mit Reject Regel verwechselt, bei der es um legitime Clients geht, die ggf. noch irgendwo hin wollen, wo sie jetzt nicht mehr dürfen, weil bspw. gerade Netztrennung noch frisch durchgeführt. Dadurch weniger Overhead/Logspam, weniger was der Admin durchsuchen muss. Und wenn ich das Log anmache wirds mit eigener ID geloggt und kann nicht mit "rogue Clients" verwechselt werden.

Macht am Ende jeder selbst so wie er möchte, ich habs nur erwähnen wollen, warum es IMHO Sinn macht, es so zu tun :)

#4

German - Deutsch / Re: OpnSense 25.10_2 HA Cluste...

Last post by JeGr - Today at 09:59:05 AM

Moin,

auch wenns schon etwas her ist:

Jedes vLAN Interface hat auf beiden Nodes eine Separate IP
Node1 10.x.x.251
Node2 10.x.x.252
CARP IP 10.x.x.1

Ist bei jedem Netz etwas anders da die Netze mal kleiner mal größer als /24 sind.

Ich würde bei CARP versuchen alle Netze gleich aufzusetzen. Also vllt. .1 als GW, .2/.3 als Nodes. Dann entfällt die Sucherei, welche IP in welchem Netz das jetzt ist und die Größe ist egal. Weniger fehleranfällig. Vor allem wäre das Arbeiten auf dem primary fix immer auf bspw. der .2.

Config sync getestet, und festgestellt das nicht alles übertragen wird. Einige Setting´s müssen manuell auf der Backup Node gemacht werden.
Ok nicht schön aber ist halt so.

Das ist aber korrekt. Vielleicht nicht ganz User-friendly aber Faustregel: alles was "Hardware" ist (also Interfaces, IF Gruppen, IP Konfiguration etc.) ist pro Node zu konfigurieren. Alles was Regelwerk, PF und Co. sowie diverse Services betrifft ist sync-bar. Aber besser nachschauen, ob der Service XY da nicht spezifische Einstellungen für hat oder eben nicht gesynct wird. Bei Zusatzpaketen ist das zB nicht immer der Fall.

Jetzt ist mir beim weiteren einrichten und nach 3 Monaten betrieb aufgefallen.
Wenn die Backup Node übernimmt, wird die Session Tabelle nicht mehr auf die Master Node übertragen.
Sie schaltet einfach zurück.
Und die Master Node blockt dann erst mal jeglichen Taffic da sie keine Sitzung dazu kennt.

Sync nicht korrekt konfiguriert? Auf dem Backup Node nicht den "General Settings" part ausgefüllt? Ohne wird kein State Sync zurück gemacht.

IPSec Tunnels die eingerichtet sind, werden sowohl auf der Master Node als auch auf der Backup Node aktiviert.

Wenn IPsec tatsächlich auf der VIP konfiguriert ist, wäre das ein Fehlverhalten. Wie ist IPsec eingerichtet? Mit der neuen Connections Methode oder eine alte Service-Konfiguration? Eventuell könnte das beim neuen Connections-Setup dann ein Fehler sein, müsste man einmal nachstellen.

Eventuell Verbanne ich die Subnet Routing Funktion ganz von der Firewall auf eine VM irgendwo

Das wäre tatsächlich bei einem Cluster praktischer. Nicht nur wegen der NAT Thematik, sondern auch wegen der Regelerstellung. Bei zwei Nodes auf Firewalls die aktiv sind, wäre es sonst fürs Routing sehr verwirrend, über welchen Node die IPs gehen und von der aktiven FW und Routing Node dann auf die passive kommen - ohne die Tailscale eigene IP zu nutzen - wäre dann ähnlich wie bei OpenVPN/WG Einwahl problematisch und bräuchte wieder einen NAT Workaround.
Darum wäre es vermutlich die geschickteste Idee die zusätzlich noch den Nutzen hätte, dass die Regeln einfacher und geschickter definiert werden können wenn man ein extra VLAN mit ein/zwei Tailscale Nodes dahinter macht (betrifft 1:1 auch das Netbird Setup BTW, funktioniert dort ja sehr ähnlich).

Als ich jetzt die Obigen HA Tests wieder gemacht hatte. War das verhalten extrem anders

Frage vorab: Hast du denn den Config Sync aktiv bzw. als Cronjob eingerichtet? Ansonsten WICHTIG: OPNsense macht KEINEN aktiven sofortigen Sync mehr. Seit längerem. Ich fände es zwar nach wie vor schön, wenn sie das als Option wieder einbauen würden, aber der Config Sync findet IMHO aktuell NICHT automatisch statt. Du brauchst also entweder nen zyklischen Cronjob der das übernimmt oder du musst manuell nach Änderungen wieder syncen, sonst passiert da nichts.

Dass dann im Betrieb die Firewalls auseinander driften in der Config und dann bei einem Failover sich vllt. sehr schräg verhalten ist leider dann kein Wunder. Das hat auch schon viele Kunden von uns getroffen, die von der Beschreibung "Sync" her einfach nicht erwarten, dass das was "Manuelles" ist oder man das nochmal extra als Cron einrichten muss, sondern dass Änderungen eben sofort gesynct und übertragen werden.

Ansonsten ist CARP/HA immer ein wenig komplex und durch die Beschreibung weiß ich jetzt spontan auch noch nicht alles, was schief gehen könnte, daher waren das nur die Punkte, die ich denke man recht schnell sehen kann. Ansonsten bräuchte man da mehr Details oder - wenn du eh schon drüber nachdenkst was anderes einzusetzen - wäre es vielleicht sinnvoll, das im Sinne von Support-Einkauf sich komplett anzusehen.

Cheers
\jegr

#5

German - Deutsch / Re: Konfiguration der Rebind S...

Last post by Patrick M. Hausen - Today at 09:36:18 AM

Schrieb ich doch. Für allow will man "LAN net" benutzen. Für deny Regeln, sofern man sie hat, "any" als Quelle.

#6

German - Deutsch / Re: Konfiguration der Rebind S...

Last post by JeGr - Today at 09:33:16 AM

Für "allow" ja. Für "deny" nein. Du willst ja auch das gehackte System blocken, das mit einer falschen Absender-Adresse als Teil eines Botnets versucht, irgendeinen Dritten zu DDoSen.

Bisschen her aber: nein will ich nicht. Denn was ich nicht erlaube wird geblockt. Allows werden nur vom <IF_net> Alias erlaubt. Deny gibts auf LAN nicht, da arbeiten wir mit Reject denn da will man dem Client sofort Feedback geben damit er die Eingabe abbrechen kann und nicht auf Timeout wartet. Und geblockt werden da eh nur interne IPs (VLAN separieren), Firewall (hat außer Mgmt keiner was drauf zu suchen) und Blocklisten extern. Das muss ich dann ggf. auch nicht loggen. Soweit die eigenen Regeln also sauber das Netzalias verwenden wäre dein Beispiel mit irgendwelchen falsch-Absendern oder Bots -> gegen default block any und deshalb eh schon geblockt. Gibt keinen Grund die mit meiner eigenen Reject Regel zu loggen, denn die will ich (Blockliste bspw.) ja als Auswertung nehmen. Die Default Blocks fallen dadurch umso mehr auf, weil es keinen Grund geben dürfte, DASS es welche gibt ;) Das hatte also schon seinen Grund.

Cheers :)

#7

German - Deutsch / Re: Verständnisfrage zu Portfo...

Last post by JeGr - Today at 09:24:18 AM

Das war auch mein Gedanke. Wenn du was "erbst" und musst es schön machen, dann kann man das ja temporär erstmal irgendwo hochfahren, dass es wieder läuft. Und wenn der Kram schon in Proxmox ist oder war und sogar in Containerform (LXC) statt VM, dann kann man das recht unspektakulär wirklich in nem VPS aufsetzen. Hatte ich selbst für ne Übergangszeit laufen, das geht. Man muss dem Proxmox selbst nur ordentlich Routing aktivieren, dann kann der das an LXCs weitergeben. Und den Container kann ich dann schön via Proxmox Backup o.ä. dann final auf einen sauber aufgesetzten neuen Dedi (z.B.) packen und migrieren, DAS geht dann eben super fix. Hab das genauso für meine eigene Spielwiese gemacht, und das war an einem Samstag mittag mit DNS umstellen und Container migrieren erledigt.

Darum vllt. in dem Fall ein veritabler Workaround?

Cheers :)

#8

German - Deutsch / Re: IPSec und NAT

Last post by JeGr - Today at 09:12:11 AM

Die OutboundNAT Regel dann auf das IPSec Interface oder WAN?

Meinem Verständnis nach outbound auf IPsec Interface, denn da geht der Traffic "raus" aus deinem Netz. Also Source dein internes LAN, Destination das Remote Netz und als Translation IP dann die bspw. .100.97/32 damit alles abgehend auf die IP umgeschrieben wird. Wenn kein eingehender Traffic geplant ist, sollte es das eigentlich tun.

Cheers

#9

25.7, 25.10 Series / Re: Unbound error

Last post by franco - Today at 08:34:06 AM

# opnsense-patch https://github.com/opnsense/core/commit/3b01394d5

Needs an apply from the unbound: general settings.


Cheers,
Franco

#10

General Discussion / Re: PSA: recent Comcast firmwa...

Last post by franco - Today at 07:49:56 AM

"allan" who reported the issue in the Comcast forum is an OPNsense user so maybe he has an update on the situation for us?


Cheers,
Franco