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