Dual OpenVPN-Setting, CARP & Failover (HA, MultiWAN)
-
Aktuelles Setting:
OpenVPN ist Vorgabe. IKEv2, Wireguard etc kommen aus unterschiedlichen Gründen in der Umgebung nicht in Frage. Die pfSense 1 soll als Master, die pfSense 2 als Slave und somit Hot Spare fungieren. Um jedoch den OpenVPN-Server 2-2 der sonst brachliegenden pfSense 2 mit nutzen zu können, werden Anfragen und Antworten von diesem vom und zum Master geroutet, die Hauptlast jedoch durch den Slave erbracht, so dass im Cluster nahezu eine Verdoppelung der VPN-Kapazitäten erreicht werden sollte (Vorkbaard hat das bereits beschrieben: https://vorkbaard.nl/openvpn-in-a-pfsense-carp-cluster/ ). Die Verwendung von jeweils 2 VPN-Servern auf jeder Appliance ist einer notwendigen Trennung in Usergruppen geschuldet.
Problemstellung:
Aus dem LAN läuft von den CoreSwitch_SFPGWs problemlos ein Pingi ins WAN. Aus dem WAN lassen sich jedoch lediglich die OPENVPN Interfaces pingen und ein Verbindungsaufbau des VPN-Clienten mit dem OpenVPN-Server scheitert mit der Fehlermeldung, der TLS Handshake sei nicht zustande gekommen. Dabei ist unklar, ob der Client den VPN-Server überhaupt erreicht. Tauscht man das dezidierte Interface des OpenVPN-Servers aus und lässt die pfSense die Route über alle Interfaces selbst suchen, erreicht sie den VPN-Server und das dahinterliegende Netz unter Umgehung der CARP-Adresse, was die CARP-Funktionalität somit außer Kraft setzt. Wo ist denn mein Denkfehler, dass ich den VPN-Server über CARP und sein Interface nicht erreiche und kein Tunnel etabliert werden kann?Wäre klasse, mir könnte da mal jemand über die Strasse helfen..
Gruß & Dank! -
@Sperber said in Dual OpenVPN-Setting, CARP & Failover (HA, MultiWAN):
Die pfSense 1 soll als Master, die pfSense 2 als Slave und somit Hot Spare fungieren. Um jedoch den OpenVPN-Server 2-2 der sonst brachliegenden pfSense 2 mit nutzen zu können, werden Anfragen und Antworten von diesem vom und zum Master geroutet
Interessanter Ansatz. Bislang wäre ich noch nicht auf eine solche Idee gekommen.
Aber wie geschieht das?Aus dem WAN lassen sich jedoch lediglich die OPENVPN Interfaces pingen und ein Verbindungsaufbau des VPN-Clienten mit dem OpenVPN-Server scheitert mit der Fehlermeldung, der TLS Handshake sei nicht zustande gekommen. Dabei ist unklar, ob der Client den VPN-Server überhaupt erreicht.
Ein Packet Capture würde da rasch Gewissheit schaffen.
Tauscht man das dezidierte Interface des OpenVPN-Servers aus
Welches ist das und was ist die Alternative?
Zu bedenken ist bei diesem Setup, dass die zweite Box grundsätzlich ihr eigenes Standardgateway hat, wohin sie Response-Pakete für öffentliche Adressen schickt, wenn das Interface der Request-Pakete nicht eindeutig ist. Das würde also ein asymmetrisches Routing nach sich ziehen. Daher sind die Regeln für das Reply-to Tagging zu beachten.
Aber auch das lässt sich mit Packet Capture schnell erkennen.
-
@Sperber said in Dual OpenVPN-Setting, CARP & Failover (HA, MultiWAN):
(Vorkbaard hat das bereits beschrieben: https://vorkbaard.nl/openvpn-in-a-pfsense-carp-cluster/ )
Die Info ist aber relativ alt und nicht zutreffen. Wir haben da sehr verschiedene und komplexe Services laufen und keiner braucht irgendwelche seltsamen Settings mit "local <extIP>" o.ä. - das sollte heute überhaupt nicht mehr nötig sein. Macht im CARP Setup auch keinen Sinn, da die CARP VIPs alle auf dem Master laufen und man diese so nicht ansprechen kann. Split CARP mit Master/Backup auf dem selben Node ist in der FreeBSD Variante von CARP/pf nicht enthalten, das ist leider nur in OpenBSD enthalten.
Mich interessiert allerdings auch wie @viragomann wie man überhaupt auf der 2. pfSense im CARP die Annahme von OpenVPN erlauben will. Der Traffic kommt ja nicht bei ihr an, weil der via CARP IMMER zur primären läuft, nicht auf den sekundären Node. Und wenn man das forwarden sollte auf Node 2, würde der Node versuchen asymmetrisch zu antworten (oder es läuft alles wieder über Node1), was auch wieder nicht sehr schön ist.
Wie ist das also realisiert, dass die Clients sich auf Node2 connecten und das auch funktioniert, wenn Node2 mal aktiv wird und Node1 passiv weil vlt. gerade gewartet wird o.ä.?
Ansonsten wäre mir schleierhaft wie das im Redundanzfall wirklich sauber funktionieren sollte ohne dass manuell eingegriffen wird?
Cheers
\jens
