Messages

i think that mDNS in the Apple way also needs configuration.

A better approach would seem to be using mDNS reflectors. Avahi can act as one.

attacking the slow dhcp
-replace the cable
-is the AutoNeg not working properly
-some kind of incompatibility on the network interface side?

LAGG between router with the Layer2 hash algorith (Load balancing) eventually is only a failover method, not increasing link capacity
Consider other hash algorithms with other layers to better balance the load.

Multi-Gig-Modes (2.5 and 5Gbps) are not a mandatory part of an implementation of 10GBaseT. In other words, if one interface advertises the mode and the other doesnt know it, they cannot link in that mode, but only in the highest common mode.

There is no way of adding the mode if the interface doesnt know it (usually, in production).

ich bin da auch irgendwann mal davor gestanden und kann noch die Anekdote anbringen, dass Routen, die von der Fritz!Box annonciert werden (z.B. weil die Netze hinter der OPNsense sind, die wiederum im LAN der Fritz!Box ist), per ICMP Redirect kommen, was von macOS per design dropped wird. Da kann man lange durch Logs gehen und den Live-Filter ansehen.

Von Tagen Troubleshooting war es 99%, bis man verstanden hat, wo der Unterschied zu anderen OS aus dem Test kommt.

Hallo Leute,
zunächst noch einmal herzlichen Dank an alle, die geschrieben haben.
Das Topic kann als (zumindest was OPNsense angeht) gelöst geschlossen werden.
Eine übers Wochenende testweise eingerichtete Sophos XG210 mit OpenVPN Client
führt zum gleichen Ergebnis, also ist irgendwas im LAN faul. Das 10.20.0.0/16
Netzwerk ist in einem Abscnitt zwischen 10.20.1.0/16 und 10.20.7,0/16 über eigene
Glasfaser verbunden, ich denke mal, das da irgendwo Medienkonverter oder ein
Switch drin verbaut sind. Obwohl Windows Clients über Ethernet alle Knoten
im gesamten Netz erreichen, können das VPN Clients über eine Firewall nicht -
sehr seltsam, hat aber hier natürlich nix zu suchen :-)

nö, kann nicht. Die Bereiche müssten 10.20.1.0/24 und 10.20.7.0/24 sein,  Deine 10.20.1.0/16 und 10.20.7.0/16 wären immer noch in 10.20.0.0/16 (korrekter: die richtige Netz-ID ist 10.20.0.0/16 für beide).. Sprich, wenn einem das so deutlich auffällt und Dir das nicht bewusst ist, könnte es sein, dass hier nicht richtig gesubnettet ist?

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!