VPN auf einem CARP HA Cluster

[hmarius1]

Hallo,

ich Teste aktuell VPN mit einem CARP Cluster. Dabei ist mir aufgefallen das wenn der Master ausfällt der VPN Tunnel nicht sofort automatisch auf die Backup Firewall umschaltet. Sollte das nicht so sein?

Muss ich auf der Firewall bei OpenVPN mit einem keepalive und bei IPSec mit Dead Peer Detection arbeiten damit VPN bei einem Ausfall schnellst möglich auf der Backup Firewall läuft?

Vielen Dank schon mal für die Hilfe.

[mimugmail]

Geht es dir jetzt um OpenVPN Server oder IPSEC?

[hmarius1]

Es geht um beide da sowohl OpnVPN als auch IPSec in Zukunft eingesetzt werden soll.

[mimugmail]

Also bei Server wird einfach der Dienst auf dem Backup neu gestartet, also User werden gekickt und müssen sich neu einwählen. Macht der Client automatisch nach dem Timeout.

Bei IPSEC ist es genauso, da kann es dann zu Problemen kommen wenn die Gegenseite die neue SA nicht akzeptiert, weil Sie meint es steht schon eine.

An sich funktioniert das alles aber.

[hmarius1]

Also OpenVPN verbindet sich nach meinen Tests nur schnell genug neu, wenn ich m Server in den erweiterten Einstellungen das keepalive eintrage das habe ich eben getestet. In den erweiterten Einstellungen steht nun der Hinweis das diese in den nächsten Versionen verschwinden könnten. Gibt es dafür eine andere Lösung falls die erweiterten Einstellungen verschwinden?

Zum Testen habe ich in den CARP Wartungsmodus geschaltet, weil dabei natürlich auch das Umschalten Fehlerfrei funktionieren soll.

IPsec Verbindungen sind damit bis jetzt nicht klargekommen. Die Verbindung ist beim Umschalten in den CARP Wartungsmodus nie getrennt worden. Es kam vor das beide Firewalls dann mit der gleichen Gegenseite über die gleiche Verbindung Verbunden waren und der Tunnel somit nicht funktionierte.

[mimugmail]

Naja, das ist halt offener Standard, multi vendor gibt's halt nicht immer seamless failover

[hmarius1]

Es muss ja auch nicht unbedingt nahtlos sein. Wenn die Verbindung für 5-10 Sekunden unterbricht ist das ja ok.

Ich habe das heute nochmal ausführlich getestet. Folgendes hat sich dabei herausgestellt. Die OPNsense die die Verbindung hält teilt der Gegenseite bei einem schwenk über den Wartungsmodus mit das Sie eine neue IP die des WAN Interfaces hat. Dadurch bleibt natürlich die Verbindung zur Firewall die nun im Wartungsmodus ist bestehen. Wir haben nun bei IKEv2 mal MOBIKE ausgeschaltet. Dadurch konnte man zumindest schonmal feststellen das die OPNsense nicht mehr offentsichtlich der anderen Gegenseite mitteilt das sie eine neue IP Adresse hat. Trotzdem bleibt die VPN Verbindung zur Firewall die sich im Wartungsmodus befindet bestehen. Man sieht auch das ESP Pakete weiterhin übertragen werden.

Stand jetzt kann ich dann nur manuell dafür sorgen das die VPN Verbindung zur Backup Firewall wechselt indem ich auf der Gegenseite die VPN Verbindung neustarte. Erst danach steht der Tunnel wieder funktionsfähig zur Verfügung.

Ich habe mit einem anderen Firewall experten über zwei Stunden nach einer Lösung gesucht. Wir waren bis jetzt erfolgslos. Vielleicht hat von euch noch jemand eine Idee.

Die einzige Idee die wir bis jetzt hatten ist das, wenn man die Firewall in den Wartungsmodus bringt, sich der VPN Dienst auf der Firewall die in den Wartungsmodus geschaltet wird dann komplett abschaltet oder zumindest eine Trennung der VPN Verbindung durchführt. Ist sowas möglich?

[mimugmail]

Äh, wieso neue IP? Mit CARP hast du doch eine floating IP die auch als Peer hinterlegt sein muss.
Eventuell hast du einfach nur einen Konfigurationsfehler?

[hmarius1]

Ich habe auch die CARP WAN IP ausgewählt in Phase 1. Mit dieser wird ja auch Kommuniziert solange ich die Firewall nicht in den Wartungsmodus schalte.

Konfiguration:
Seite A (Cluster):
Phase1
Anschlussart: Nur Antworten
IKEv2
Protokoll: IPv4
Schnitstelle: x.x.x.130 (VIP WAN)
Ferner Gateway x.x.x.10
Auth: Mutual PSK
Kennung: Meine IP Adresse
Peer Identifizierer: Peer IP-Adresse
Verschlüsslung.: AES 265
Hash: SHA512
DH Group: 14
Lebenszeit: 28800
NAT Traversal: Deaktivieren
Mobike: deaktiviert
Dead Peer Detection: 10 Sek 5 Wiederholungen

Phase2
Lokales Netzwerk:
VLAN Subnetz
Entferntes Netzwerk:
172.xx.xx.0/24

Protokoll: ESP
Verschlüs: AES 265
Hash: SHA512
PFS Group: 14
Lebenszeit: 3600

Seite B:
Lokales Gateway: x.x.x.10
Lokale Gateway ID: x.x.x.10
Remote Host: x.x.x.130
Remote Host ID: x.x.x.130
Initiate Connection: Outgoing
Dead peer Detection: On
Verschlüsslung.: AES 265
Hash: SHA512
DH Group: 14
Lebenszeit: 28800

Phase2
Lokales Netzwerk:
172.x.x.0/24
Entferntes Netzwerk:
192.xx.xx.0/24

Verschlüs: AES 265
Hash: SHA512
PFS Group: 14
Lebenszeit: 1hours

[mimugmail]

Poste mal die Logs. Da darf sich nicht die IP ändern

[hmarius1]

Nachdem MOBIKE deaktiviert wurde ist das in den Logs mit der geänderten IP nicht mehr sichtbar.

Im Log sieht man jetzt aber das nach kurzer Zeit keine Kommunikation von beiden Seiten mehr stattfindet das log endet nach den folgenden Einträgen:

OPNsense Master die zur Backup wird:
charon: 08[IKE] <con1|144> giving up after 5 retransmits
Jun 28 08:34:32   charon: 11[NET] <con1|144> sending packet: from xx.xx.xx.130[4500] to xx.xx.xx.10[4500] (96 bytes)
Jun 28 08:34:32   charon: 11[IKE] <con1|144> retransmit 5 of request with message ID 15
Jun 28 08:33:50   charon: 11[NET] <con1|144> sending packet: from xx.xx.xx.130[4500] to xx.xx.xx.10[4500] (96 bytes)
Jun 28 08:33:50   charon: 11[IKE] <con1|144> retransmit 4 of request with message ID 15
Jun 28 08:33:27   charon: 11[NET] <con1|144> sending packet: from xx.xx.xx.130[4500] to xx.xx.xx.10[4500] (96 bytes)
Jun 28 08:33:27   charon: 11[IKE] <con1|144> retransmit 3 of request with message ID 15
Jun 28 08:33:14   charon: 13[NET] <con1|144> sending packet: from xx.xx.xx.130[4500] to xx.xx.xx.10[4500] (96 bytes)
Jun 28 08:33:14   charon: 13[IKE] <con1|144> retransmit 2 of request with message ID 15
Jun 28 08:33:07   charon: 13[NET] <con1|144> sending packet: from xx.xx.xx.130[4500] to xx.xx.xx.10[4500] (96 bytes)
Jun 28 08:33:07   charon: 13[IKE] <con1|144> retransmit 1 of request with message ID 15
Jun 28 08:33:03   charon: 13[NET] <con1|144> sending packet: from xx.xx.xx.130[4500] to xx.xx.xx.10[4500] (96 bytes)
Jun 28 08:33:03   charon: 13[ENC] <con1|144> generating INFORMATIONAL request 15 [ ]
Jun 28 08:33:03   charon: 13[IKE] <con1|144> sending DPD request
Jun 28 08:32:57   charon: 11[KNL] xx.xx.xz.1 disappeared from lagg0_vlan30
Jun 28 08:32:57   charon: 10[KNL] xx.xx.xg.130 disappeared from igb1
Jun 28 08:32:57   charon: 10[KNL] xx.xx.xa.1 disappeared from lagg0_vlan20
Jun 28 08:32:57   charon: 10[KNL] xx.xx.xx.1 disappeared from lagg0_vlan34
Jun 28 08:32:57   charon: 10[KNL] xx.xx.xy.250 disappeared from igb3_vlan35
Jun 28 08:32:57   charon: 10[KNL] xx.xx.xb.1 disappeared from lagg0_vlan10
Jun 28 08:32:57   charon: 10[KNL] xx.xx.xf.250 disappeared from lagg0
Jun 28 08:32:53   charon: 10[ENC] <con1|144> parsed INFORMATIONAL response 14 [ ]

OPNsense Backup die zur Master wird:
Jun 28 08:32:58   charon: 07[KNL] xx.xx.xy.250 appeared on igb3_vlan35
Jun 28 08:32:58   charon: 07[KNL] xx.xx.xz.1 appeared on lagg0_vlan30
Jun 28 08:32:58   charon: 16[KNL] xx.xx.xg.130 appeared on igb1
Jun 28 08:32:58   charon: 16[KNL] xx.xx.xa.1 appeared on lagg0_vlan20
Jun 28 08:32:58   charon: 16[KNL] xx.xx.xb.1 appeared on lagg0_vlan10
Jun 28 08:32:58   charon: 16[KNL] xx.xx.xf.250 appeared on lagg0
Jun 28 08:32:58   charon: 16[KNL] xx.xx.xx.1 appeared on lagg0_vlan34

Gegenseite:
08:33:27.572331 IP xx.xx.xx.130.4500 > xx.xx.xx.10.4500: NONESP-encap: isakmp: child_sa  inf2
08:33:27.572537 IP xx.xx.xx.10.4500 > xx.xx.xx.130.4500: NONESP-encap: isakmp: child_sa  inf2[IR]
08:33:50.965308 IP xx.xx.xx.130.4500 > xx.xx.xx.10.4500: NONESP-encap: isakmp: child_sa  inf2
08:33:50.965475 IP xx.xx.xx.10.4500 > xx.xx.xx.130.4500: NONESP-encap: isakmp: child_sa  inf2[IR]
08:34:32.962585 IP xx.xx.xx.130.4500 > xx.xx.xx.10.4500: NONESP-encap: isakmp: child_sa  inf2
08:34:32.962752 IP xx.xx.xx.10.4500 > xx.xx.xx.130.4500: NONESP-encap: isakmp: child_sa  inf2[IR]

[mimugmail]

ipsec.log von backup die zur master wird?

[hmarius1]

Ich habe mal die Anschlussart von Antworten auf Starten in der OPNsense gestellt. Dort ergab sich dann folgendes:

Ich habe nun den Auslöser des Problems gefunden. Die Master Firewall, die zur Backup Firewall wird beendet nicht den IPsec Tunnel und sendet weiterhin über die CARP IP ESP Pakete zur Gegenstelle. Die Backup Firewall stellt in dem Moment eine Verbindung zur Gegenseite her. Demnach sind nun beide Firewalls über die VIP WAN mit der Gegenstelle verbunden und senden auch beide Pakete an die Gegenstelle. Dabei ist die neue VPN Verbindung zur Backup Firewall, die ja nun Master ist, auch voll funktionsfähig, Wenn man nun den Wartungsmodus wieder beendet ist die Verbindung ja immer noch auf der Master Firewall aufgebaut und dadurch scheint der Tunnel dann dicht zu sein.

Eine Lösung für das gesamte Problem wäre also das die OPNsense bei umschalten in den Wartungsmodus den Dienst oder die Verbindung zur Gegenseite auf der Master Firewall beendet. Dann würde auch nach dem beenden des Wartungsmodus der Tunnel neu aufgebaut und die Verbindung ist wieder voll funktionsfähig.

Gibt es eine Möglichkeit auf der OPNsense einzustellen das wenn der Wartungsmodus aktiviert wird das die VPN Tunnel geschlossen werden?

[mimugmail]

Kannst du mal im Wartungsmodus schauen ob  auf das primären Firewall das WAN inteface wirklich auf Backup steht? Sieht mir eher nach einem Config Problem aus.

[JeGr]

> Sieht mir eher nach einem Config Problem aus.

Würde ich momentan ebenso sehen. Bei IPSEC & CARP darf nach einem Schwenk oder manuell via Wartungsmodus weder die WAN-VIP noch aktiv sein, noch darf der ehem. Master dann noch Daten senden, da er de-facto die IP gar nicht mehr hat. Der IPSec sollte dann eigentlich auch gestoppt/restartet werden, weil das ein NIC Ereignis ist?

Anyway, bei OpenVPN Keepalive ist Client Sache, nicht Server. Sprich wenn du kürzere/kurze Neueinwahl Zeiten haben möchtest, solltest du ein keepalive Setting konfigurieren, das ist korrekt. Zusätzlich solltest du mal bei den Server Custom Options noch den Parameter

    explicit-exit-notify 2;

setzen, was @derelict von Netgate/pfSense uns beim Thema CARP/Failover mitgegeben hat. Sollte es einen harten Ausfall geben (Powerloss, Line-Down) wird das natürlich nicht helfen, dann ist das Keepalive gefragt, aber bei einem manuellen Schwenk oder Konfigurationsänderung wird der Server dem Client kurz mitteilen, dass er down geht und er sich doch bitte gleich neu einwählt (funktioniert allerdings nur via UDP, nicht bei TCP Servern!).
Die Ziffer ist übrigens ausschlaggebend (bei mehreren Remote Parametern), ob sich der Client beim gleichen Server meldet oder zum nächsten weiterspringt sollte man in der Client Konfiguration mehrere haben (als Fallback/Backup).

Grüße