[Solved]: IPSec Failover - Grundsatzfrage zum Verständnis

[tblum]

Moin!
Ich schlage mich mittlerweile seit Wochen mit der Einrichtung einer IPSec-Vebindung herum, die den Ausfall eines Providers verkraften würde. Mein Szenario ist auf Seite A eine opnsense im Dual-WAN-Betrieb, am WAN-Interface eine Kabel-Fritzbox, am pppoe0-Interface ein Vigor-130-VDSL-Modem. Auf Seite B eine Opnsense auf einem gehosteten Server mit fixer IP. Für die beiden IP-Adressen auf Seite A habe ich einen dynDNS-Eintrag, den ich auf eine der beiden IPs legen kann. Ich bekomme die Verbindung gut hin, aber wenn ich den dynDNS-Eintrag "umschalte", dann will die Verbindung nicht wieder zustande kommen. Wenn ich das Forum hier durchsuche, bin ich wohl auch nicht der Einzige mit diesem Problem, allerdings gibt es auf die Fragen dazu bisher keine Antworten. Alles, was ich bisher im Internet dazu finden konnte in Anleitungen für andere Firewall-Systeme, waren Lösungen mit VTI-IPSecs. Deswegen nun erstmal meine grundsätzliche Frage: Funktioniert ein Failover für IPSec-Verbindungen über verschiedene Provider generell nur mit VTI-IPSecs? Oder sollte das prinzipiell auch über policy based IPSecs gehen und ich bin nur zu doof?
Falls ersteres der Fall ist, wäre ich sehr dankbar, wenn mir jemand erklären könnte, warum das so ist. Falls letzteres zutrifft, würde ich mehr Informationen zu meiner Konfiguration liefern und wäre sehr froh, wenn mir jemand den Fehler aufzeigen könnte.

[Patrick M. Hausen]

Ich kann nicht mit 100% Sicherheit sagen, dass Policy based nicht funktionieren kann, tendiere aber dazu. Letztendlich willst du ja dynamisch routen. Dazu braucht es ein Routing-Protokoll und keine Policy. Die Policies sind starr, auch wenn der Tunnel "weg" ist. Es wird dann eben versucht, den Tunnel aufzubauen, auch wenn das nicht klappt.

Ich habe früher in meiner Cisco-Zeit immer IPIP- oder GRE-Tunnel aufgebaut und über diese dann OSPF gesprochen. Wenn das Routing funktioniert hat, dann IPsec im Transport Mode drauf gelegt.

[trixter]

Man könnte auch etwas simpler heran gehen:

2 Statische Routen mit unterschiedlicher Metrik z.B. 200 und 100.
Solange beide Gateways "up" sind, wird die mit der besseren Metrik (200) genutzt.
Geht diese jedoch "down" würde die andere (100) gültig.

[Patrick M. Hausen]

Stimmt. Ist aber eben keine Policy sondern Routen 

[tblum]

Danke, Patrick, das bestätigt in etwas das, was sich mir so erschließt. Schade, dass das nicht irgendwo deutlicher dokumentiert ist, das hätte mir einiges an Zeit erspart. Dann versuche ich mein Glück mal mit einem VTI-Tunnel.

[JeGr]

> Danke, Patrick, das bestätigt in etwas das, was sich mir so erschließt. Schade, dass das nicht irgendwo deutlicher dokumentiert ist, das hätte mir einiges an Zeit erspart. Dann versuche ich mein Glück mal mit einem VTI-Tunnel.

Ich habe das leider noch nicht mit einer OPNsense testen können, aber mit eine pfSense funktioniert dein beschriebenes Szenario mit DynDNS und IPsec im normalen Routing Mode mit P2s genau so wie gedacht:

Aufbau:

Seite A: 3x WAN, IPsec ist konfiguriert auf einer GW Gruppe, so dass bei WAN1 Ausfall entsprechend WAN2/3 genutzt wird. OPNsense sollte das automatisch hinbekommen meine ich. Zusätzlich ein DynDNS Service eingerichtet, der prüft, welches WAN aktiv ist und die entsprechend aktive IP setzt.

IPsec IKE v2 konfiguriert mit Identifier als DNS mit DynDNS Namen als "MyID" und "RemoteID" einen Hostnamen der Remote Site. Gateway ist der Hostname der Gegenseite (fixe IP/DNS Name auf fixe IP, geht beides)

Gegenseite ist konfiguriert mit einzelnem WAN aber korrekt konfiguriertem DNS Hostnamen auf diese IP. Hier ist MyID der Hostname und RemoteID der DynDNS Name. Gateway ist hier ebenfalls der DynDNS Name.

Bei Schwenk der IP wird dann die DynDNS IP geändert via API beim Hoster, und der Tunnel versucht sich mit den neuen Daten frisch aufzubauen. Die Gegenseite braucht dann ab und an so zwischen 1-5min bis sie den DNS Namen refreshed hat, dann geht der Tunnel aber wieder up. Der Knackpunkt ist da wirklich die ID (dyndns Name) sowie das Gateway (ebenfalls der dyndns) der korrekt gesetzt sein muss, sonst meckert immer die Gegenstelle, dass es entweder einen ID oder GW Konflikt gibt.

Müsste das nochmal in OPNsense nachbauen, rein technisch kann es aber sowohl die Sense als auch der Charon/IPsec Daemon, somit ists - wenn überhaupt - noch nen UX Thema. Es könnte aber auch schlicht schon funktionieren. Eventuell klemmts aber noch am Refresh vom DynDNS beim IPsec Aufbau der Seite B (wo die statische IP klebt), denn wenn die die IP der DynDNS Adresse nicht aktualisiert, könnte sie natürlich beim GW Aufbau in ein Problem laufen. Ansonsten sollte das aber entweder mit der ID via Dyndns Name oder ID per selbst gesetzten nonsense IPs funktionieren.

Cheers
\jens

[Patrick M. Hausen]

Das finde ich jetzt ziemlich kurios. Ich würde einfach pro externer IP-Adresse/Uplink einen separaten Tunnel konfigurieren und auf den Tunneln ein Routingprotokoll fahren. Thema durch. Umschaltzeit 30s, kein DynDNS nötig.

[JeGr]

Ist nicht möglich da Gegenstelle das nicht unterstützt. Wir können uns leider die Gegenseite nicht immer aussuchen und DAS ist zumindest ein Ding, das eben ohne großen Act oder zusätzliches Routing Protokoll funktioniert. Mit einer Gegenseite, die schon mit VPN Problemen hat auch noch Dinge wie OSPF oder BGP zu bauen wäre manchmal ein Albtraum. Klar geht es immer schöner, aber ich wollte das zumindest mal einwerfen, dass es technisch absolut machbar ist wie @tblum meinte und DynDNS da auch kein falscher Ansatz ist. Mind. für das remote GW der Gegenseite wirds gebraucht je nachdem was an ID unterstützt wird und was man da eingetragen bekommt. Und dann funktioniert das auch im Test recht smooth.

[Doerchi]

Hi trixter,

hast du das mit den zwei statischen Routen mal ausprobiert?
Ich wollte es mir einfach machen und wollte es nutzen, leider schwenken die Routen nicht. Auch wenn ich das Main-Gateway auf down schalte, wird die zweite Route nicht aktiv.
Laut des Hilfe-Buttons
"Choose a value between 1 and 255. Influences sort order when selecting a (default) gateway, lower means more important."
Gewinnt die kleinere Priorität. Aber egal wie ich es anstelle, die statischen Routen schwenken nicht.
Getestet mit Version 24.7.2