FW Rules werden teilweise nicht angewendet
-
Hallo!
Ich lasse meinen Anschluss von thinkbroadband.com regelmäßig anpingen um einen Graphen beim "Broadband Quality Monitor" zu erstellen. Das klappt auch einwandfrei. Auf WAN habe ich daher folgende Regel definiert:
Nach einem Reboot der pfSense funktioniert das Ganze auch tadellos. Starte ich allerdings nur das Modem neu, kommt die Regel nicht mehr zum Einsatz. Die IP Adresse die via DHCP bezogen wird, ist dabei die Gleiche. Auch DynDNS ist nicht das Problem. In den States sehe ich die Verbindung noch:
Lösche ich diese State, funktioniert es auch wieder. Die Frage ist also: warum wird die State so lange (12 Stunden) aufrecht gehalten? In den Firewalllogs sieht man nur dass ICMP vor dem Neustart des Modem noch durchgelassen wurde. Einen Block gibt es nicht.
-
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.