FW Rules werden teilweise nicht angewendet
-
Hallo!
@mrsunfire said in FW Rules werden teilweise nicht angewendet:
Die Frage ist also: warum wird die State so lange (12 Stunden) aufrecht gehalten?
Kann ich dir auch nicht beantworten. Aber vielleicht hilft ein Haken bei
System > Advanced > Miscellaneous > State Killing on Gateway Failure.
Sollte dann die zugehörigen States von selbst löschen. -
Würde sicherlich helfen, aber damit riskiere ich schon einen Verbindungsabbruch bei Packetloss. Das möchte ich vermeiden. Und da mein WAN1 eine DOCSIS Verbindung ist, ist Packetloss leider nicht so selten.
-
@mrsunfire Einfach nicht das Modem neu starten? Mir ist das Problem zumindest noch nicht begegnet.
Außerdem ist meine Regel schöner.
PS: Hab mal mein Compal neugestartet, hier konnte ich das Problem nicht nachstellen.
https://www.thinkbroadband.com/broadband/monitoring/quality/share/ff7f02b33eb797e0339fed26ef8668270e3b0360
-
Ich habe den Hacken bei mir gesetzt.
Wenn bei einer DOCSIS Verbindung loss auftaucht und das über die Warnung hinaus geht, ist das Internet definiv down.
Das merke ich ja meist schon zuvor, wenn ich aus einem Game raus fliege oder Seiten nicht mehr laden.Habe ich die GUI offen, sehe ich Warnung, muss ich die erst laden, ist da gleich Down zu sehen.
Dafür läuft gleich alles wieder, wenn das Modem wieder hoch kommt.
-
@Bob-Dig Na ich starte es normal nicht neu, aber wenn es mal sein muss sollte der Graph halt wieder laufen. Das Problem tritt erst seit Firmwareversion .41 beim TC4400 auf. Mit meiner .33 gibt es dieses Problem nicht, da der Link kurzzeitig down geht. Ich vermute hier den dynamischen IP Wechsel (von 192.168.100.10 auf public IP) als Ursache.
@NOCling said in FW Rules werden teilweise nicht angewendet:
Ich habe den Hacken bei mir gesetzt.
Wenn bei einer DOCSIS Verbindung loss auftaucht und das über die Warnung hinaus geht, ist das Internet definiv down.
Das merke ich ja meist schon zuvor, wenn ich aus einem Game raus fliege oder Seiten nicht mehr laden.Habe ich die GUI offen, sehe ich Warnung, muss ich die erst laden, ist da gleich Down zu sehen.
Dafür läuft gleich alles wieder, wenn das Modem wieder hoch kommt.
Ich habe meist nur wenige % Loss. Auch wenn es dann auf die Backupleitung umschaltet, fliege ich nicht gleich aus einem Spiel raus, das das durchaus verkraften kann.
-
@mrsunfire Hast Du "Reject leases from >Modem<" aktiviert? Wen nicht, aktivieren.
-
Nein, habe ich nicht. Denn ich möchte ja auf das Modem kommen wenn die HFC Verbindung oder der WAN Uplink down ist um die Leitungswerte bzw. die Ursache einzusehen.
-
@mrsunfire Das geht auch so. Es geht hier nur darum, keinen störenden und unnützen dhcp lease zu bekommen. Das ganze gilt natürlich nur für Modems, nicht für Router (es sei denn im Bridge-Mode).
-
Wenn keine IP vorhanden ist, komme ich auch nicht aufs WebIF?
-
@mrsunfire Wir reden hier von WAN-IP, eine lokale IP hast Du ja eh fest, genauso wie das Modem diese gezeigte feste IP hat und auch behält. Teste es einfach selbst.
-
Genau. Am WAN verliere ich meine Public IP und wenn ich keine lease vom Modem zulasse, erhalte ich dort eine 0.0.0.0. Demnach wird auch die 192.168.100.1 fürs Modem dort nicht hin geroutet.
-
@mrsunfire Ich habe lange keine Ausfälle mehr in der Art gehabt, wahrscheinlich weil ich eben diese Option in pfSense gesetzt habe! Ich kann sie daher nur empfehlen. Wie es sich nun genau bei einem Ausfall verhält, kann ich aber tatsächlich nicht mehr sagen, aber bedenke, genau für so einen Ausfall gibt es ja die Option...
-
Na die ganze Zeit hat das immer problemlos geklappt. Mir ist es wichtiger dass ich von Remote aufs Modem schauen kann, als dass der Graph von alleine neu startet. Mich interessiert nur der Hintergrund, warum die pfSense das macht.
-
@mrsunfire Ok, deine Leitung kommt ja wieder hoch, nur der Graph geht nicht, bei mir war es dann doch anders, und die Leitung kam nicht wieder zurück. Wahrscheinlich besteht da doch kein Zusammenhang.
-
Ja, sobald das HFC Netz wieder da ist (ohne Modemneustart) kommt die IP und auch der Graph geht! Das Problem tritt nur auf, wenn ich das Modem von Hand neustarte. Ist demnach absolut unkritisch und nur ein Schönheitsfehler, oder eben ein Bug von der pfSense.
-
Ich komme auch so aufs Modem, da die Default Router meiner FW auf das WAN zeigt und da kommt dann auch das 192.168.100.0/24 hin, weil ich das lokal nicht nutze.
Teste es doch einfach mal, schalte den Kabel Verstärker ab oder ziehe das Coax und schaue ob du drauf kommst.
-
Klar komm ich dann drauf, weil der pfSense ja dann die 192.168.100.10 zugeteilt wird. Unterbinde ich das, komme ich nicht mehr drauf.
-
@mrsunfire Die Lösung bzgl. Zugriff auf 192.168.100.1 kann hier gefunden werden:
https://forum.netgate.com/topic/149298/arpresolve-can-t-allocate-llinfo-for-192-168-100-1/22
Man kann ja weitere statische IP-Adressen zu einem Port festsetzen und entsprechendes Routing konfigurieren. -
Ich habe kein Problem mit dem Zugriff aufs Modem, aber danke. Die VIP nutze ich nun ebenfalls um den arp Fehler zu unterbinden.
-
Ich hole das Thema mal wieder hoch, da es nun nachweislich auftritt. Ich habe nun neben den normalen WAN, noch ein Test WAN angelegt. Neues Interface, sonst nichts. Nur eine Regel die greifen soll (was sie auch vorerst tut).
Geht nun dieses WAN kurz down und kommt wieder online, wird die Regel nicht mehr angewendet! Man sieht sie jedoch noch Stunden danach unter den States:
Erst wenn ich die States lösche, greift die Regel wieder. Wie werde ich diesem Problem Herr?
