FW Rules werden teilweise nicht angewendet
-
@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.
