Gateway Monitor IP … so macht das wenig Sinn!
-
Selbst wenn ich mehrere IPs vom Provider bekomme, die vIP für das CARB-WAN-Interface kann ich nicht per DHCP bekommen weil das nicht vorgesehen ist und es für diese IP auch keine mac-Adresse gibt.
Also wie soll das praktisch gehen? Ich brauche genau für die vIP ja eine, die tatsächlich auch bei mir ankommt.Abgesehen davon löst das mein Problem mit dem Monitoren nicht.
gruß
Abgesehn davon … IPv4-Adressen hat man ja eh eher zu wenig! jetzt davon zwei zu blockieren, ohne sie zu brauchen, ist nicht sehr nützlich!
Die Frage bleibt: Warum kann ich für das KABEL-Interface nicht die gleiche Monitor-IP auf beiden pfSensen vergeben? Bzw. warum zeigt dann die zweite pfSense das Gateway dann als DOWN an, obwohl auch von da aus diese IP erreichbar ist? -
Um deine Frage zu beantworten, es macht nicht wirklich Sinn die gleiche IP zu Monitoren, weil man üblicherweise die Gateway IP monitort und, wenn das dich gleiche ist und alles über ein Gateway geht ist es doch eh irrelevant, weil dann alle beide Gateways down sind.
Warum die Gatway IP als Down markiert wird kann ich dir leider nicht beantworten, da dieses Konzep für mich keinen richtigen Sinn ergibt.
Die IP's die ich besitze, nutze ich auch für unterschiedliche Zwecke. Somit ist es keine Verschwendung. Zumal es ja mit IPv6 mehr als genug ips gibt!
Im eine Firmenumgebung hat man meist ein Netzsegment mit dem man auch eine WAN IP als CARP Interface erstellen kann.
In meinem Fall arbeite ich mit 3 verschiedenen Dyndns Adressen. Eine pro Pfsense und eine die Hinter den Pfsense liegt und die aktuelle Adresse nach außen anzuzeigen, denn der Client der hinter den Pfsense liegt, geht ja immer einen der 3 möglichen Wege raus.
Wenn du mir beschreiben könntest was du mit der CARP WAN IP vor hast, dann könnte ich besser darauf eingehen.In dem Szenario wie du es jetzt beschrieben hast und ich es verstanden habe, hast du doch erst recht keine WAN IP die balanced wird?
Wenn ich den Szenario richtig verstanden habe gehst du doch nur über eine Leitung raus, da ist es doch egal was du anpingst, wenn das Gatway down ist oder die fritzbox, dann ist doch für beide pfsense Schluss oder nicht?
-
Moin bitboy0,
nur eine Bitte, kannst Du bitte CARB durch CARP ersetzen?
So findet man Deine Beiträge per Suche zum Thema besser ;)-teddy
-
Um deine Frage zu beantworten, es macht nicht wirklich Sinn die gleiche IP zu Monitoren, weil man üblicherweise die Gateway IP monitort und, wenn das dich gleiche ist und alles über ein Gateway geht ist es doch eh irrelevant, weil dann alle beide Gateways down sind.
Beide pfSensen haben das gleiche WAN, dieses die gleiche Gateway-IP und beide prüfen ob sie dieses Gateway erreichen können. Das ist logisch und funktioniert bei dem UMTS-WAN und bei DSL. nur bei Kabel geht es nicht.
Warum die Gatway IP als Down markiert wird kann ich dir leider nicht beantworten, da dieses Konzep für mich keinen richtigen Sinn ergibt.
Jedes WAN hat natürlich ein anderes Gateway, aber es geht ja hier um EIN WAN und da haben alle CARP-Cluster die selber Gateway-IP um es nutzen zu können.
Die IP's die ich besitze, nutze ich auch für unterschiedliche Zwecke. Somit ist es keine Verschwendung. Zumal es ja mit IPv6 mehr als genug ips gibt!
IPV6 ist hier leider noch nicht möglich.
Im eine Firmenumgebung hat man meist ein Netzsegment mit dem man auch eine WAN IP als CARP Interface erstellen kann.
Keine Idee wovon du redest! Wir haben hier ein Kabelmodem von Cisco und von KabelBW eine feste IP für EINE mac-Adresse dahinter.
DynDNS brauche ich nicht. Ich habe feste IP-Adressen und über den DNS bei Hosteurope kann ich subdomains der Firmendomain dahin verbinden.Wenn du mir beschreiben könntest was du mit der CARP WAN IP vor hast, dann könnte ich besser darauf eingehen.
Erneut verstehe ich deine Frage nicht. Damit CARP funktioniert muss ich logischerweise eine vIP vergeben und diese dann als externe Adresse angeben. Alle Anfragen von Außen müssen auf diese vIP gehen, die tatsächlichen IP's der Interfaces spreche ich von Außen ja nicht an, muss diese aber vergeben und die dürfen auch keinem anderen gehören.
Da ich nur eine IP vom Provider habe geht diese auf eine Fritzbox. Die Fritzbox hat ein eigenes kleines Netz:
FB 10.10.11.1 -> DMZ auf 10.10.11.254
PF1 10.10.10.252
PF2 10.10.10.253
vIP 10.10.10.254 (muss im gleichen Netz liegen wie die festen IPs)So hat jedes echte Interface eine IP und es gibt im gleichen Netz eine vIP auf die der Traffic gelenkt wird.
Nur so kann pfSense bei Bedarf den Slave benutzen um zu arbeiten, dann wird die vIP einfach von dem benutzt, nicht mehr vom Master.In dem Szenario wie du es jetzt beschrieben hast und ich es verstanden habe, hast du doch erst recht keine WAN IP die balanced wird?
Nach meinem Verständnis habe ich NUR so die Möglichkeit zwei pfSensen an einen WAN zu hängen und Redundanz an der Stelle zu bekommen.
Klar KANN die Fritzbox ausfallen, oder das Cisco-Modem davor. DANN ist WAN2 als Reserve da, das DSL. Da ist ebenfalls eine Fritzbox als Moden und Router davor:FB 10.10.12.1 -> DMZ auf 10.10.12.254
PF1 10.10.12.252
PF2 10.10.12.253
vIP 10.10.12.254Also wenn irgendwas im KabelWAN ausfällt wechselt pfSense zu DSL. Das klappt auch.
Wenn ich den Szenario richtig verstanden habe gehst du doch nur über eine Leitung raus, da ist es doch egal was du anpingst, wenn das Gatway down ist oder die fritzbox, dann ist doch für beide pfsense Schluss oder nicht?
Nein, hast du offensichtlich nicht verstanden. Wir haben DREI WANs …
Jedes WAN hat den gleichen Aufbau und jedes WAN soll natürlich auf UP/DOWN getestet werden. Das was pfSense als Gateway benutzt ist aber immer die Fritzbox/UMTS-Router. Wenn die Leitung dahinter ausfällt kann pfSense den Router aber noch erreichen und anpingen und bekommt nichts von dem Ausfall mit. Wenn ich aber das Gateway des PROVIDERS anpinge (natürlich das jeweis passende) zeigt pfSense beim KABEL-WAN nur auf dem ersten NODE UP an, auf dem zweiten, der über die Fritzbox am gleichen WAN hängt aber als DOWN.
Die Prio ist Kabel, DSL, UMTS ... also normal benutzt er Kabel, fällt das aus dann DSL, geht das auch nicht dann UMTS.Bei DSL und UMTS funktioniert das anpingen des jeweiligen Gateways, beim Kabel nur auf der ersten Kiste. DARUM geht es !
-
Hi!
Da ich nur eine IP vom Provider habe geht diese auf eine Fritzbox. Die Fritzbox hat ein eigenes kleines Netz:
FB 10.10.11.1 -> DMZ auf 10.10.11.254
PF1 10.10.10.252
PF2 10.10.10.253
vIP 10.10.10.254 (muss im gleichen Netz liegen wie die festen IPs)Hast du dich bei den IP Adressen verschrieben? Die DMZ und die VIP sollten wohl die gleiche sein.
Deine Logik, eine FritzBox dazwischen zu setzen, um die Ausfallsicherheit zu erhöhen, kann ich auch nicht teilen, aber das mag Geschmack- und Vertrauenssache sein. Und laut Berichten in anderen Threads sollte CARP nun seit Version 2.2 auch mit WAN IPs in einem anderen (privaten) Netzwerksegment funktionieren, allerdings klappen einige Funktionen damit nicht, apinger gehört da wohl dazu.
Wie auch immer, grundsätzlich müsste apinger auf beiden pfSense unabhängig funktionieren. Die pfSense macht dabei ja nichts anderes, als einen Ping von seiner WAN IP abzusetzen. In deinem Fall geht der über die FB, die NAT macht und wenn die Antwort aus dem Internet kommt, sollte die FB wieder per NAT das Paket an die Absender-IP, also die richtige pfSense, weiterleiten. Dass das bei dir nicht klappt, ist gewiss nicht normal und sollte behebbare Ursachen haben.
Untersuche eventuell mal den Datenfluss auf der Schnittstelle mit einem Paket Capture Tool.
Ansonsten erzähl mal was über die Hardware, worauf die pfSensen laufen.Grüße
-
Sorry, ja, da hab ich nach copy&paste die ip's nicht richtig geändert. sind natürlich alle im gleichen Netz!
http://varia-store.com/Systeme-mit-Software/pfSense/pfSense-19-Komplettsystem-mit-2x-APU1D4-1GHZ-Dual-Core-4GB-R::3261.html
Das ist die Hardware… klein, günstig und problemlos.Zur Ausfallsicherheit; Jedes WAN hat einen eigenen kleinen Router. Empfehlung von JeGR. Also wenn eine der Fritzboxen ausfallen sollte geht das zugehörige WAN nicht mehr, selbst wenn es am Eingang der Fritzbox noch anliegt. Allerdings hatte ich in den letzten 10 Jahren nur 2 Ausfälle einer Fritzbox. Da es da nicht auf genau eine bestimmte Hardware ankommt, ist es kein Problem einen Ausfall zu beheben. Dafür ist ja das zweite WAN da, um dann einzuspringen.
Die Idee CARP zu benutzen kam nach dem missglückten Update von 2.1 auf 2.2! Jetzt kann ich in so einem Fall einfach CARP temporär ausschalten, eine der Kisten Updaten und sehen ob alles geht. Entweder ich gehe dann zurück auf die Version davor, oder ich kann die zweite Kiste dann updaten, wenn die erste Kiste alles gut überstanden hat. Davon merkt kein Anwender etwas und ich muss nicht zwingend warten bis in die späte Nacht.
Also durch CARP gibt es eine Redundanz für pfSense. Durch insgesamt 3 WAN gibt es Redundanz wenn ein WAN oder eine Fritzbox ausfällt.
Den Switch, der alle WAN zusammenfasst und mit VLAN auf die pfSense bringt, habe ich zwei mal da liegen. Der zweite ist schon fertig konfiguriert und könnte einfach durch 1:1-Umstecken in Betrieb genommen werden.Für UNS ist diese Lösung ausreichend sicher. Auch mein Kollege kann zur Not den Switch tauschen und es gibt eine Vollständige Dokumentation im Feuerschrank, falls ich mal im Urlaub bin und die Welt zusammenbricht.
gruß
-
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,
-
@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
