CARP: WAN Konfig Frage
-
Moin.
Mal ne Verständnisfrage zur WAN-Konfig in einem CARP Cluster. Ich habe mein CARP anhand des Beispiels wie in den pfSense Docs konfiguriert. Allerdings bedeutet das bei der jetzigen Konfiguration den Einsatz von 3 "offiziellen" IP-Adressen (Zwei für die Hardware WAN Schnittstellen, eine für die VIP). Eigentlich müsste es doch möglich sein, nur die VIP mit einer offiziellen IP zu versehen und die WAN Interfaces mit privaten IPs und dann "irgendwie" mit entsprechenden NAT-Regeln zu behandeln. Der (Provider-)Router vor der pfSense reicht ein offizielles /27 IPv4 Netz durch.
Von daher habe ich zwar ausreichend v4 Adressen für die Kisten, aber verschwenden muss man sie ja auch nicht unbedingt.Also: Ist das möglich? Gibt es ggf. irgendwelche Probleme mit Diensten die direkt auf der Firewall, bzw. dahinter laufen?
Momentan läuft schon eine IPSec Verbindung produktiv über die aktuelle Config. Diese sollte möglichst danach immer noch funktionieren, falls ich da was ändere… -
Minimum of three IP addresses per subnet (one for primary, one for secondary, one or more for CARP VIPs) – This can be avoided on pfSense 2.2, but is still recommended.
Ja das ist seit pfSense 2.2 möglich.
-> https://doc.pfsense.org/index.php/High_Availability
-
This can be avoided on pfSense 2.2, but is still recommended.
Klingt nach: "Zu Risiken oder Nebenwirkungen fragen Sie Ihren Arzt oder Apotheker".
Dann lass ich lieber erstmal die Finger davon. Experimentieren kann ich mir hier nicht erlauben.Trotzdem danke für den Hinweis!
-
Klingt nach: "Zu Risiken oder Nebenwirkungen fragen Sie Ihren Arzt oder Apotheker".
Nö. Es ist eine Variante, die seit dem Umstieg auf FreeBSD 10 zur Verfügung steht, weil damit auch pf und carp in neuer Version zur Verfügung stehen und nun keine physikalisch gleiche IP mehr auf dem Interface brauchen für CARP. Dass es trotzdem empfohlen ist, liegt eher in der sinnvolleren Debugging und Netzlayer Verfügbarkeit weil man von außen sonst die Knoten direkt einfach nicht erreichen kann. Das hat aber nichts mit Funktion zu tun.
Ist hier zu sehen: https://forum.pfsense.org/index.php?topic=87546.0
Läuft seit 2015 schon.Gruß
-
Dass es trotzdem empfohlen ist, liegt eher in der sinnvolleren Debugging und Netzlayer Verfügbarkeit weil man von außen sonst die Knoten direkt einfach nicht erreichen kann.
Das ist natürlich ein gutes "Pro"-Argument. Dann lass ich die Konfig so wie sie ist.
