Messages

danke Dir! Schönen Restsonntag!

Stimmt, Firewall states flushen nach Regeländerung.

wenn ich bei nicht erfolgreichem PING die ICMP allow Regel einschalte und danach wieder aus, beginnt erst der PING und läuft dann auch nach Ausschalten weiter. Aber ist ja vielleicht keine Änderung :)

In der Doku habe ich irgendwas über Firewall/Rules/States gelesen - aber gibt es auch einen Terminalbefehl zum Flushen der Rules? pfctl -F all?

Hm, gerade noch einmal ausprobiert. Verhalten bleibt gleich. Flushen der Rules hilft nicht. Die beiden Optionen unter Firewall/Diagnostics/States/Action bringen auch nichts. pfctl -F all bringt nichts. Nur die Option 11 (Reload all services) von der Shell hilft. Was ist das denn für ein Feature?

Ich danke Euch für die Hilfe. Ich habe den Fehler gefunden: Beim Blick aufs general firewall log fiel mir ein Fehler bei einer Rule auf, danach hat er wohl nicht mehr erfolgreich importieren können (was wohl auch heißt, dass schon seit einiger Zeit die Änderungen gut für gar nichts waren).
Die Rule war benannt, ich habe sie gelöscht und in dem Augenblick klappte sowohl das Logging im Live-View, als auch das Blocking.

ich habe alle Floating-Rules und alle WAN-Rules auf Logging enabled gesetzt und im Logfiles/Live-View nach meiner source gesucht. Taucht nicht auf.

Ich bin ratlos.

Hast Du die ICMP Regel erst grad deaktivert (und 'Apply' gedrückt)? Es kann einen kleinen Moment gehen bis keine offenen 'states' mehr gibt.

ich habe vorsichtshalber sogar rebootet...

In der Datei /tmp/rules.debug findest Du die aktiven pf Regeln, guck mal rein ob Du was findest betreffend ICMP echoreq.

habe ich mir auch gerade angesehen, entweder bin ich betriebsblind oder da ist tatsächlich nichts offensichtliches.

Mach mal einen Paketdump mit "tcpdump -i <WAN> -X icmp" und schau, ob die Pakete ankommen und ob geantwortet wird.

gute Idee, tun sie

Übrigens: Die alte Regeln mit "Floating vor..." gilt m.W. mit den neuen Regeln nicht mehr. Hast Du schon migriert?

nein. Ich glaube, das Verhalten habe ich auch schon ewig, also deutlich vor 26.1

WAN gibt nicht antwort auf Ping per default, da hast Du eine Regel dafür erstellt (auf dem WAN Interface?.

wenn das so offensichtlich wäre, würde ich ja nicht fragen :) - ein wenig Ahnung habe ich schon. Vielleicht kann man meine Frage umstellen: Wieso antwortet eine OPNSense auf PINGs, obwohl sie das standardmäßig nicht tut und auch keine Konfiguration in den Regeln sein sollte, die das doch erlaubt.
Der Vollständigkeit halber: ich habe tatsächlich auf dem WAN Interface Regeln, die ICMP erlauben, aber diese sind disabled (lt. GUI). Aber selbst wenn sie enabled wären, lt. Doku ist die Reihenfolge Floating, dann Interface-Regeln, dann der Rest.  Die Verbotsregel steht in den Floating-Regeln ganz oben.

Hast Du den eine eigene öffentliche IP, also eine die nicht mit 100.64... bis 100.127... anfängt?

ja

Und also Folgefrage, bist Du ganz sicher, dass Deine OPNsense antwort gibt? Gibt es eine Gerät vor der OPNsense?

es gibt kein Gerät davor, demzufolge sollte es die OPNSense sein, die antwortet

Und auf welche OPNsense Version setzt Du ein?

OPNsense 26.1.4-amd64

Hallo,
stelle mich wahrscheinlich zu blöd an. Ich würde gerne IPv4 ICMP Type 8 (Echo Request) eingehend auf dem WAN interface mit der Aktion DROP versehen.
Zu diesem Zweck habe ich bereits eine Floating Regel mit dem passenden Inhalt erstellt und sie ganz nach oben geschoben. Wenn ich die automatically generated rules aufklappe, sehe ich nichts, was den Fall regeln oder widersprechen würde.

Aus dem Internet bekommt man aber noch Antworten.

Gibt es da noch irgendein weiteres Setting?

i tested so far with ftp, one stream only. Many thanks for your insight, i will continue to test and concentrate on Bandwidth-Delay Product, after i tested if this is not accidentally a pure "Killer-Feature". :) I will revert.

BTW: This was a follow-up to https://forum.opnsense.org/index.php?topic=49839.msg253185#msg253185 (i had a shaper active). But i have too much to do and cannot remember the iperf3 test results so i will have to redo them.

Hello,

i finally have my Windows game pc in its own subnet (malware/ransomware isolation precautions). I can reach my LAN (which for the OPNsense is WAN) and have actively disabled outbound-NAT for known source/destination subnets. The hardware is a Topton 4x i226v/2x 82599 with Pentium Gold 8505. When transferring from/to the Windows host, the data transfer obviously caps at 113MB/s (tested ftp). The physical interfaces (2x 2,5Gbps from the Topton, 1Gbps from Windows) are link up and advertised/linked up at 2,5Gbps on the same switch (CRS310).

Is there some known thing with the current community OPNsense version? (hope so).

Any test ideas/advice? My next thing would be to place a generic host with !=Windows and try transfer rate with because the network chip on the game rig is a ,,Killer" (RTL8125-based i think) with its own optimization software.

Thankyou!

so, gefunden: fast zu peinlich, es zuzugeben, vor allem, da man es ja selbst verbrochen hat:
Firewall/Shaper/Pipes, dort waren Begrenzungen entsprechend meines Internetanschlusses eingetragen. Das habe ich probeweise nicht mehr enabled, jetzt geht's schnell.

Ich danke Euch vielmals!

die VM hat mich nicht veralbert, das Verhalten mit 2,5Gbps ist mit dem Windows-Host genauso. Wenn der Ubuntu sendet bekomme ich 2,37Gbps, wenn der Windows-Host sendet (im LAN), dann nur ein Gbps. Warum auch immer.

ich habe noch eine SSD gefunden und bin gerade beim Testen mit einer Basisinstallation mit deaktivierter Firewall.

In der Tat, Routing scheint unproblematisch zu sein. Wenn die VM sendet, gehen 1Gbps, wenn der Ubuntu-Host sendet, gehen 2,37Gbps. Das verstehe ich noch nicht (der Ubuntu-Zielhost und der Hypervisor ist mit 10Gbps angeschlossen, die Firewallinterfaces können 2,5Gbps): wenn da was limitiert, dann doch bitte bei Senden *und* Empfangen.

Was mit den 200Mbps sind- in mir keimt eine Vermutung, wenn ich so durch meine Aufzeichnungen gehe. Ich will noch mal den Windows-Host testen und dann zurückbauen. Und dann schau ich in die Richtung.

Das bringt sowieso so gut wie nichts mit der Jumbo MTU.

äh, nein... Kommt natürlich drauf an, aber ob man 5Gbps oder 10Gbps bekommt (auf der bis auf die SSD selben schwächlichen Hardware) würde ich durchaus nicht als "nichts" bezeichnen. Jede aktuelle Hardware kann das auch und es macht sowohl rechnerisch wie auch praktisch einen Unterschied. Es hat Fallstricke, ja, aber hier war ja schon der Beweis erbracht, dass es nichts damit zu tun haben kann.

Aber gut, for the sake of the argument, sowohl der Windows-Host, als auch die VM, als auch der Ubuntu-Zielhost und die Firewall-Interfaces stehen auf MTU 1500. Test wiederholt. Selbes Ergebnis.

Ich denke, ich gehe mal an die Grabbelkiste, ob noch eine SSD da ist und dann installiere ich ein OPNsense Basispaket und schau, wie sich das verhält. Vielleicht habe ich zuviel und an den falschen Stellen herumgepfuscht (aka irgendwelche Empfehlungen übernommen).

Hallo,
habe jetzt crowdsec und Sensei deinstalliert über den Paketmanager und rebootet.

Keine Veränderung der Routing-Performance, immer noch ca. 200Mbps. Dann habe ich den physischen Windows-Host gestartet (im selben Subnetz), habe von dem auch getestet und im Rahmen der Testgenauigkeit kommen da auch pi mal Daumen 200Mbps heraus.

Spricht demnach dafür, dass es nicht an Sensei/crowdsec gelegen hat.

Nur an was? Die Firewall der OPNsense ist derzeit deaktiviert (Firewall/Settings/Advanced/Disable all packet filtering).

An der Stelle sei erwähnt, dass  die MTU auf dem Ubuntu Zielhost im WAN auf 9000 steht, aber ICMP komplett erlaubt ist. Außerdem habe ich gegengeprüft mit --length 1000 und --length 8972 - die Ergebnisse bleiben gleich. Zumindest mit relativ kleiner MTU hätte ich eine Änderung erwartet, wenn Pakete neu assembliert hätten werden müssen. Die Firewall selbst lasse ich auf 1500 (wg0 bei 1380).

danke Dir! Ich probiere das aus. Allerdings ist Zenarmor ganz neu, ich hatte ja vorher den n5105 - und da hatte ich dieselbe lausige Performance. Deshalb bin ich ein wenig skeptisch.