Messages

obwohl ich alle Fehler beseitigt habe war heute morgen plötzlich "Firewall waiting Data..."
im Dashboard.... nach ein Paar Tagen problemloser funktion?

Kann auch keinen Ansatz dafür finden.... nach eine reboot wieder alles gut, wie lange!?

ja, habe ich.

Ich habe Fritzbox mit exposed host und Bridged, gesamt 4 IP 2x ip4 und 2 ip6.

habe 2 Gateway Gruppen mit Ausfall Option, aber kein Richtlinien basiertes Routing für wireguard.

ddns läuft über Exposed Host, und darüber greife ich auf Wireguard.


Habe jetzt weiter expirementiert es läuft in 2 Versionen:

1x Status Typ > kein, Zustandrichtlinie > Standard

1x Status Typ > Status behalten, Zustandrichtlinie > Interface

mit anderen Optionen läuft es nicht.

@Monviech

nun so begabt bin ich doch nicht das ich mit der Shell freund bin.

aber ich habe mal experimentiert und als ich die Option Zustandsrichtlinie statt Standard auf Interface gesetzt habe lief es...

in der alten Rule Version ist es auf Standard.

Sollte man die Option global setzen in den Firewall optionen!?

Erstelle ich diesselbe regel unter Regeln>Global und deaktiviere unter Regel new.

Läuft es.

You cannot view this attachment.

Also irgendein Wurm in den neuen Regeln drin.

nach Migration der Regel funktioniert WG nicht, spiel man sicherung vor Migration>läuft.

Erstellt man regel manuell>läuft nicht.

Es wird anscheinend was übertragen aber ich sehe nicht wo geblockt und warum.

You cannot view this attachment.

[gleichzeitig!]

So, Firewall waiting Data Problem gelöst!

Ascheinend erlaubt die Neue Version Angabe von Gateway und reply-to interface gleichzeitig! das habe ich als
Feature verstanden und die regeln so konfiguriert das der hin und rückpdad bestimmt war.

Das war der Fehler!
in der Version 25.7 war dies nicht möglich, da hatte die Sense sofort gemeckert mit den hinweis entweder oder.

Hoffe das es wieder kommt als "ideotensicherung" sozusagen.

das ist klar, ändert aber gar nichts....

du kannst alle wählen oder abwählen ändert nichts an "Defaul Deny" mit zb. DF Flag. (nur Option "jeglich" beendet diese Phänomen)

auch Normalisierung mit "IP-Flag "Nicht fragmentieren" zulassen ändert da auch nichts.

es geht um diese option in den Regeln bei TCP, ohne diese produziert Sense false positive Default denys trotz freigegebenen ports.

You cannot view this attachment.

mit Rucksicherung von 25.7.11 auf Image 26.1.4 läuft wireguard wieder.... also irgendwas beim Import/konvertierung der regeln läuft schief.

hatte heute vor alle Funktionen zu prüfen beim 26.1 Wechsel....

Wireguard lief nicht, habe alles mögliche freigeschaltet was zu freischalten war >nichts!
ich konnte am WAN auch nicht sehen das irgendeine Externe IP auf port 51820 anklopft....

also mal Sense neugestartet! danach war am Dashboard bei Firewall app nur Data loading.... und das wars!

1 Sicherung zurück>nix 2 Sicherung zurück>nix, bis ich die Sicherung vor 26.1 geladen habe, danach lief die Sense wieder....

Irgendwas kaputt an der neuen 26.1.4?

Diese option war vor 26.1 in den Firewall Regeln vorhanden und war Hilfreich bei
False Positive Meldungen unter Default Deny.

You cannot view this attachment.


Was ist jetzt zutun? Kommt die Option wieder?

hatte Problem mit KEA IP6 DHCP.

egal was ich als ip range/scope eingetragen habe alles falsch>fehler.

Gut das ich noch ISC konfig behalten habe, KEA weg ISC wieder aktiv > Läuft.

ich schätze das ist sowas wie microsoftische Art.... du fragst nach Doppelfenster bei Windows Explorer, kriegste aber rundere Icons beim nächsten Update... :)

Ja! die Übersichtlichkeit ist flöten.... früher habe ich bei den Rules auf untersuchen geklickt und direkt gesehen wieviel bytes übertragen und States
vorhanden sind.... konnte direkt auf die states klicken und was sehen jetzt habe ich irgendwo recht irgendwas mit ></253 xyz bewertung... keine Ahnung wie es mir helfen soll...

Hatte mich auch auf neues Livelog gefeut das es endlich wie früher ist, man klickt auf zb. Default deny und sofort ist Fenter damit aufgegangen jetzt klickt man egal wohin es öffnet sich immer allgemeines fenster und man muss sich filter selber stricken.

ich meinte auf der seite unter:

Hardware & Driver Settings

dev.igc.0.fc    0    1    Disable flow control on igc0 0=disabled 1=enabled
dev.igc.1.fc    0    1    Disable flow control on igc1 0=disabled 1=enabled
dev.igc.2.fc    0    1    Disable flow control on igc2 0=disabled 1=enabled
dev.igc.3.fc    0    1    Disable flow control on igc3 0=disabled 1=enabled
dev.igc.0.eee_control    0    1    Disable Energy Efficient Ethernet 0=disable 1=enabled
dev.igc.1.eee_control    0    1    Disable Energy Efficient Ethernet 0=disable 1=enabled
dev.igc.2.eee_control    0    1    Disable Energy Efficient Ethernet 0=disable 1=enabled
dev.igc.3.eee_control    0    1    Disable Energy Efficient Ethernet 0=disable 1=enabled
hw.igc.max_interrupt_rate    20000    8000    Max interrupts per second (10k). 8000 is also good and keep latency low. You can test with higher values if you have better ethernet card
hw.igc.enable_aim    2    1    Adaptive interrupt moderation. 2=low latency Adaptive Interrupt Moderation (AIM) — dynamically adjusts interrupt rate based on load., 1=normal Static interrupt moderation — not adaptive. (Fixed delay intervals), 0=disabled Every packet (or small
group) triggers immediate interrupt. Lowest latency, highest CPU interrupt rate

du kannst mal die Werte unter
System>einstellungen>optimierung testen.

schon mal die seite besucht?

https://github.com/nightcomdev/opnsense/tree/main/tunables

die hardware  sparte wäre interessant.