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.
-
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?
-
Kann ich nur nochmal auf @viragomann hinweisen. Wenn es das Problem ist, dass States aktiv bleiben (warum überhaupt) auf dem WAN das down geht und nach dem UP dann die Verbindungen nicht mehr laufen, dann solltest du über den Haken mit "State Killing on GW failure" nachdenken und den setzen.
Darauf hattest du aber leider nicht geantwortet außer dass dus nicht möchtest. Deine Argumentation
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.
ist aber etwas widersinnig, bei "nur" packet loss greift der Haken nicht. GW failure ist klar definiert als "GW DOWN" und das passiert erst bei >20% packet loss. Bei >10% kann ich schon nicht mehr ordentlich arbeiten, da ist mir dann völlig wurscht ob die FW schon bei 10 oder erst ab 20% anfangen würde States wegzuwerfen. Anyway das wird nicht einfach so bei 1-2% loss mal aus Jux getriggert. Daher würde ich das testen.
Auch wenn mich mehr interessieren würde wie es überhaupt sein kann, dass da States so lange bleiben :)
-
Ja, das interessiert mich eben auch. Zumal das Problem "neu" ist. Ich nutze seit bald 10 Jahren pfSense und habe das Problem erst seit einigen Monaten. An den Einstellungen habe ich dabei aber nichts geändert.
-
@mrsunfire Habe ja nun auch seit einiger Zeit Probleme mit Packetloss an der pfSense und meinem Kabelanschluss...
Ein Gedanke noch, ThinkBroadband nutzt auch IPv6, je nachdem, was Du dort eingetragen hast. Von daher auch mal deren IPv6 freigeben oder sichergehen, dass die hinterlegte Adresse nur zu IPv4 auflöst.
Da wir gerade drüber reden, habe ich mich mal eingeloggt und was sehe ich da? Kein Wunder, dass ich gestern heftigst gelaggt und heute einen neuen Anschluss bestellt habe. OMG
PS: Wenn ich mich so durch die Tage klicke, sind es schon öfters Bilder des Grauens, verstörend und faszinierend zugleich.
-
Ne, Ingress habe ich eigentlich kaum. Wenn, dann ist die Leitung meist wirklich down nachts, wegen Wartungsarbeiten. Danach geht nur leider der Graph nicht mehr, dabei ist es auch egal ob IPv4 oder v6. Die States sind offen, werden aber nicht mehr genutzt. Für mich ist das ein Bug seit 1-2 Versionen.
