Gateway Monitor IP … so macht das wenig Sinn!
-
@amfootbal4live:
Also soweit ich das sehen kann und verstanden habe, ist das Problem soweit klar.
Die Firewalls sind Active/Passive, richtig?
Wenn die zweite FW (passive) ein ICMP (ping) sendet kommt das Antwortpaket zurueck und wird zur "Active" gesendet.
Diese verwirft das Paket, weil sie nichts damit anfangen kann.
Asynchronous routing nennt sich das….Wenn ich das richtig sehe, sollte das bei keinem Setup funktionieren, ausser Du wuerdest eine "stateless" Firewall haben,
Nein … ein abgehendes PING geht über die echte WAN-IP der passiven Sense raus und wird auch dahin beantwortet. Bei DSL geht es und bei UMTS auch, nur bei Kabel geht es oft nicht. Grade eben ist es wieder auf beiden Sensen "up" ... gestern war es nur auf der ersten "UP" und manchmal war es nur auf der zweiten "UP" ... da die kleinen Netze vor dem WAN-Anschluss der Sense zum Provider (Fritzbox) jeweils genau gleich aufgebaut sind, muss es an Kabel-BW liegen ... aber die wissen natürlich auch nicht was da los ist, ich glaub nicht mal das die verstanden haben was ich gefragt habe seufz
gruß
-
Nein … ein abgehendes PING geht über die echte WAN-IP der passiven Sense raus und wird auch dahin beantwortet. Bei DSL geht es und bei UMTS auch, nur bei Kabel geht es oft nicht. Grade eben ist es wieder auf beiden Sensen "up" ... gestern war es nur auf der ersten "UP" und manchmal war es nur auf der zweiten "UP" ... da die kleinen Netze vor dem WAN-Anschluss der Sense zum Provider (Fritzbox) jeweils genau gleich aufgebaut sind, muss es an Kabel-BW liegen ... aber die wissen natürlich auch nicht was da los ist, ich glaub nicht mal das die verstanden haben was ich gefragt habe seufz
gruß
Aua, ja das kenne ich gut! Mann stellt die Fragen so genau als moeglich. Sie verstehen es trotzdem nicht.
Hast Du schon mal gesnifft, ob das Paket irgendwie zurueck kommt? Auf der Sense kansst Du tcpdump laufen lassen.
Dann koennstest Du sehen, ob das an Deinem Setup liegt oder das Paket irgendwo verschluckt wird… -
@tommytiger: Das Setup macht so durchaus Sinn. Ich habe meine zentrale Firewall Instanz HA gebaut, damit sie nicht ausfällt. Meine WANs kann ich aber ggf. eben technisch nicht HA haben, weil mir Telekom/Kabel/whoever eben keinen HA Uplink liefert. Den liefert mir ggf. nur ein richtig teurer Anbieter oder ein Datacenter. Da habe ich dann gegenüber meist die gleiche Konstellation wie ich selbst: einen CARP/VRRP/HSRP Cluster, der mir den Uplink liefert.
Ob die Fritzbox jetzt ein SPOF ist oder nicht, das wäre sie so oder so. Es ist egal, ob das jetzt eine FB ist, ein Provider-Router oder sonst irgendwas, wie oben gesagt, wenig Provider bringen mir tatsächlich einen HA-Uplink. Das heißt aber nicht, dass ich deshalb hintendran bei meiner Firewall auf HA verzichten kann/soll, denn dort mache ich meine ganzen Regeln, verwalte meine VPNs oder meine Benutzer. Hier ist also wichtig, dass die Kiste durchgehend läuft, denn im Normalfall bin ICH dafür verantwortlich (gegenüber meinem Chef o.ä.). Wenn die FB/Modem/Router des Providers ausfällt und kein Internet da ist -> Provider/ISP. Da bin ich dann aber auch aus der Schuldfrage raus und auch nicht in Haftung oder im Kreuzfeuer, weil ich was verbockt habe. Und wenn - so wie bei Bitboy0 - mehrere WANs zur Verfügung stehen, gibts dann eben ein Failover auf DSL oder LTE. Aus dem Grund kann man bei solch einem Setup selten ein Modem o.ä. einfach direkt an WAN anschließen. Du könntest sonst höchstens noch was mit BGP oder OSPF mauscheln, aber dann wirds schon arg hakelig. Einwahl per DSL geht ja dann auch nur auf einem Knoten, der andere müsste nach Übernahme sich dann selbst einwählen. Und wer stellt dann fest, dass der Uplink funktioniert? Wie definiere ich dann ein WAN Ausfall?
@bitboy0: Insofern macht es schon Sinn, dass das Gateway gecheckt wird - nämlich der "Providerrouter" vorne dran. Das sagt dir - korrekt - nicht aus, ob das WAN Bein down ist. Man will ja aber auch kein Failover, nur weil das WAN down ist auf Node #2, sondern nur dann, wenn wirklich Node #1 nicht mehr mit dem Router reden kann (Switch Problem, Kabelbruch, NIC defekt) auf Node #2 umschalten. In deinem Fall machst du aber zusätzlich noch Failover Multi-WAN, und dafür musst dus natürlich wissen, sonst kann ja keine andere Gateway Gruppe aktiv werden.
Kann es sein, dass das Problem evtl. an dem ausgewählten Host liegt? Hast du für jedes Gateway einen eigenen externen Host als Check angelegt? Wir machen das mitunter mit den Google DNS Servern oder anderen Kisten, die mutmaßlich immer an sein sollten und gute PING Latenzen haben. Wenn diese zu gering sind, kann hier durchaus auch ein GW Down kommen (siehe APinger Alerts im Log!). Es könnte also eine Überschneidung der Pings sein, der Zielhost, Timing, etc.
Außerdem nochmal prüfen ob die Kabel FB auch sauber die pfSense Host IPs genauso NATtet wie die VIP. Nicht dass das ein NAT Problem ist.
Grüße
-
Ja, also das ist eben STRANGE!!!
Grade sieht es SO aus… erste Sense zeigt alles grün, zweite erzählt was von extrem hässlichen RTT's ...
Aber wenn ich die erste Sense ausstecke oder die zweite mal neu starte ist alles grün auf beiden.... bz. es funktioniert ohne Problem.Diese schräge Anzeige habe ich nur wenn ich das GW des Providers anpinge oder eine andere externe IP ..
Wenn ich auf der Slave Sense die IP für das Gatway-Monitoring ändere, dann hab ich auf jeder Sense eine andere für dieses GW und es bleibt stabil grün. Also Probleme habe ich nur wenn auf der Master-Sense eine Monitoring-IP eintrage, und die über CARP auf den Slave genauso eingetragen wird.
gruß
-
Gerade wegen dieses Phänomens habe ich ja gefragt, ob du vorne dran die FB mal gecheckt hast, ob:
- pfSense 1/2 sauber mit IHRER Adresse pingen können (nicht mit der CARP IP) - und das auch durchaus mal gleichzeitig
- mit der CARP IP testen - sollte auf dem Slave nicht funktionieren da keine Antwort ankommt und er das IF nicht hat
- das ganze am Besten von der Console aus machen, nicht von der GUI (also per SSH bspw.), damit man mehr als nur 3-4 Pings sieht und wie die sich entwickeln.
Ggf. mal das MTR Paket installieren und nen mtr 8.8.8.8 auf beiden Kisten abfeuern (oder die IP eures externen Servers) und da mal beobachten. Könnte auch durchaus sein, dass die FB da ein Problem hat bei NAT und 2 Pings zur gleichen Zeit die sauber zurück zu NATten, andernfalls könnte es auch ein apinger Problem sein.
Grüße
-
Ja, also einzeln geht das alles direkt von der IP der Sensen und auch der vIP …
So wie ich das sehe nutzen die Sensen für das Gatway-Monitoring NICHT die vIP, sondern die fest zugewiesenen.Es ist durchaus möglich, dass die FB da einfach bei mehreren, sich überschneidenden, ICMP-Anfragen auf EINE IP die Antworten nicht zuverlässig zurück routet.
Mit jeweils eigenen IP's für's Monitoring geht es prima... aber ist natürlich nicht optimal.gruß
-
Mit jeweils eigenen IP's für's Monitoring geht es prima… aber ist natürlich nicht optimal.
Da stimme ich dir absolut zu. Evtl. müsste man das Problem allerdings auch mal in den englischen Teil bzgl. apinger eskalieren, ob das doch vllt. ein blöder Nebeneffekt ist oder das wirklich an der FB vorne liegt.
Grüße
-
Ich nehme fast an, dass die Fritzbox da ein Problem hat. Es scheint so, als würden die PING-Anfragen fast genau zur gleichen Zeit rausgehen… dann kann es natürlich passieren das sich die Antworten nicht in der Reihenfolge der Anfrage einfinden. Das sollte zwar EGAL sein, ist es aber anscheinend nicht. Das Problem tritt nur auf, wenn die Monitor-IP im WAN liegt und es die gleiche IP für beide Nodes ist.
Interne Anfragen (auf die Fritzbox-IP) oder Anfragen auf unterschiedliche externe IP's klappen immer... selbst wenn die Anfrage auf den gleichen Server laufen der mehrere IP's auf seinem Interface unterstützt...Jedenfalls kann ich bei manuellen Pings über die Konsolen der beiden Sensen keine Probleme feststellen... aber die sind ja auch nie SO syncron...
Ich hab den Brocken mal AVM vor die Füße geworfen und bin gespannt ob/wie die auf die Anfrage reagieren.
wenn da nix bei rum kommt werden ich das mal versuchen im englischen Teil abzusondern...gruß
-
@bitboy0 Hey, habe genau das selbe Problem. Hast du nach 8 Jahren hierfür eine Lösung gefunden?
-
@alexander90 said in Gateway Monitor IP … so macht das wenig Sinn!:
@bitboy0 Hey, habe genau das selbe Problem. Hast du nach 8 Jahren hierfür eine Lösung gefunden?
Antworten
He? Echt? Nach 8 JAHREN antwortest du auf einen steinalten Thread bei dem noch dazu eine steinalte pfSense Version mit im Spiel ist, dass du jetzt das gleiche Problem hast? Ich bezweifle das ja etwas. Das exakt gleiche vermutlich nicht. Wie wäre es einfach nen neuen Thread mit genau deinem Problem auf zu machen statt einen uralt Thread auszugraben? :)
Cheers
