IPSec Tunnel bauen sich nicht automatisch wieder auf

[OPNFox]

Hallo zusammen,

trotz der Einstellung, dass der Tunnel sich direkt starten soll, habe ich bei mehreren OPNSense den Fall, dass der VPN Tunnel sich einfach nicht mehr automatisch aufbaut.

Der VPN liegt z.B. zwischen FritzBox und OPNSense als auch OPNSense zu OPNSense.
Alle Anschlüsse haben Dyn IPv4 Adressen.

Ich muss manuell einmal zur OPNSense mich aufschalten und in der IPSec Übersicht manuell den Tunnel, der auf einem "orangenen Pfeil" steht, noch einmal mit einem Klick auf diesen Pfeil starten.

Das ggf. zuerst die Verbindung fehl schlägt, kann ich beim IPv4 Wechsel der IP nachvollziehen, wenn noch die falsche IP aufgelöst wird. Nur wieso versucht die Firewall es nicht alle paar Minuten immer wieder bzw. wie bekomme ich das hin?

[OPNFox]

Hm, keiner eine Idee, wieso das passiert bzw. wie man es verhindert oder zumindest behebt?

Wäre es ggf. sinnvoll, wenn ich es im englischen Forum poste?

[jimjohn]

Was sagen denn die Logs nach Neustart? Irgendwelche Hinweise?

[schnipp]

Hallo zusammen,

trotz der Einstellung, dass der Tunnel sich direkt starten soll, habe ich bei mehreren OPNSense den Fall, dass der VPN Tunnel sich einfach nicht mehr automatisch aufbaut.

Damit sich der Tunnel nach einem Abbruch automatisch wieder aufbaut, musst Du diesen auf "Start on traffic" stellen.

[OPNFox]

Was sagen denn die Logs nach Neustart? Irgendwelche Hinweise?

Schwierig, da einfach kaum etwas zu sehen ist.

Firewall A will eine Verbindung zum Firewall B aufbauen.
Bei Firewall B sieht man nichts in den IPSec Logs, bei Firewall A sieht man:

Code Select Expand

2021-08-29T20:46:23 charon[91089] 09[IKE] <con2|20875> establishing IKE_SA failed, peer not responding
2021-08-29T20:46:23 charon[91089] 09[IKE] <con2|20875> giving up after 5 retransmits
2021-08-29T20:45:07 charon[91089] 08[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:45:07 charon[91089] 08[IKE] <con2|20875> retransmit 5 of request with message ID 0
2021-08-29T20:44:25 charon[91089] 07[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:44:25 charon[91089] 07[IKE] <con2|20875> retransmit 4 of request with message ID 0
2021-08-29T20:44:02 charon[91089] 10[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:44:02 charon[91089] 10[IKE] <con2|20875> retransmit 3 of request with message ID 0
2021-08-29T20:43:49 charon[91089] 10[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:43:49 charon[91089] 10[IKE] <con2|20875> retransmit 2 of request with message ID 0
2021-08-29T20:43:42 charon[91089] 05[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:43:42 charon[91089] 05[IKE] <con2|20875> retransmit 1 of request with message ID 0
2021-08-29T20:43:38 charon[91089] 05[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:43:38 charon[91089] 05[ENC] <con2|20875> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
2021-08-29T20:43:38 charon[91089] 05[IKE] <con2|20875> initiating IKE_SA con2[20875] to 1.12.12.12
2021-08-29T20:43:38 charon[91089] 05[IKE] <con2|20875> peer not responding, trying again (3/3)
2021-08-29T20:43:38 charon[91089] 05[IKE] <con2|20875> giving up after 5 retransmits
2021-08-29T20:42:22 charon[91089] 13[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:42:22 charon[91089] 13[IKE] <con2|20875> retransmit 5 of request with message ID 0
2021-08-29T20:41:40 charon[91089] 13[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:41:40 charon[91089] 13[IKE] <con2|20875> retransmit 4 of request with message ID 0
2021-08-29T20:41:17 charon[91089] 16[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:41:17 charon[91089] 16[IKE] <con2|20875> retransmit 3 of request with message ID 0
2021-08-29T20:41:05 charon[91089] 14[CFG] received stroke: route 'con2'
2021-08-29T20:41:05 charon[91089] 11[CFG] added configuration 'con2'
2021-08-29T20:41:05 charon[91089] 11[CFG] received stroke: add connection 'con2'
2021-08-29T20:41:05 charon[91089] 13[CFG] deleted connection 'con2'
2021-08-29T20:41:05 charon[91089] 13[CFG] received stroke: delete connection 'con2'
2021-08-29T20:41:05 charon[91089] 14[CFG] received stroke: unroute 'con2'
2021-08-29T20:41:04 charon[91089] 14[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:41:04 charon[91089] 14[IKE] <con2|20875> retransmit 2 of request with message ID 0
2021-08-29T20:40:57 charon[91089] 14[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:40:57 charon[91089] 14[IKE] <con2|20875> retransmit 1 of request with message ID 0
2021-08-29T20:40:53 charon[91089] 09[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:40:53 charon[91089] 09[ENC] <con2|20875> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
2021-08-29T20:40:53 charon[91089] 09[IKE] <con2|20875> initiating IKE_SA con2[20875] to 1.12.12.12
2021-08-29T20:40:53 charon[91089] 09[IKE] <con2|20875> peer not responding, trying again (2/3)
2021-08-29T20:40:53 charon[91089] 09[IKE] <con2|20875> giving up after 5 retransmits
2021-08-29T20:40:49 charon[91089] 07[CFG] received stroke: route 'con2'
2021-08-29T20:40:49 charon[91089] 09[CFG] added configuration 'con2'
2021-08-29T20:40:49 charon[91089] 09[CFG] received stroke: add connection 'con2'
2021-08-29T20:40:49 charon[91089] 07[CFG] deleted connection 'con2'
2021-08-29T20:40:49 charon[91089] 07[CFG] received stroke: delete connection 'con2'
2021-08-29T20:40:49 charon[91089] 10[CFG] received stroke: unroute 'con2'
2021-08-29T20:39:37 charon[91089] 14[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:39:37 charon[91089] 14[IKE] <con2|20875> retransmit 5 of request with message ID 0
2021-08-29T20:38:55 charon[91089] 14[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:38:55 charon[91089] 14[IKE] <con2|20875> retransmit 4 of request with message ID 0
2021-08-29T20:38:32 charon[91089] 13[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:38:32 charon[91089] 13[IKE] <con2|20875> retransmit 3 of request with message ID 0
2021-08-29T20:38:32 charon[91089] 11[CFG] received stroke: route 'con2'
2021-08-29T20:38:32 charon[91089] 15[CFG] added configuration 'con2'
2021-08-29T20:38:32 charon[91089] 15[CFG] received stroke: add connection 'con2'
2021-08-29T20:38:32 charon[91089] 11[CFG] deleted connection 'con2'
2021-08-29T20:38:32 charon[91089] 11[CFG] received stroke: delete connection 'con2'
2021-08-29T20:38:19 charon[91089] 05[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:38:19 charon[91089] 05[IKE] <con2|20875> retransmit 2 of request with message ID 0
2021-08-29T20:38:12 charon[91089] 05[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:38:12 charon[91089] 05[IKE] <con2|20875> retransmit 1 of request with message ID 0
2021-08-29T20:38:08 charon[91089] 05[NET] <con2|20875> sending packet: from 192.168.17.2[500] to 1.12.12.12[500] (464 bytes)
2021-08-29T20:38:08 charon[91089] 05[ENC] <con2|20875> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
2021-08-29T20:38:08 charon[91089] 05[IKE] <con2|20875> initiating IKE_SA con2[20875] to 1.12.12.12
2021-08-29T20:38:08 charon[91089] 06[CFG] received stroke: initiate 'con2'



Die IPs sind abgewandelt.
Da auf beiden Seiten eine FritzBox am WAN hängt und die OPNsense nur per ExposedHost etc. freigegeben ist, könnte es natürlich auch sein, dass hier irgendetwas hängen bleibt.
Wobei es ja direkt wieder funktioniert, wenn ich auf beiden Firewalls etwa zeitgleich den reconnect der VPN anwerfe.


"Start on traffic" bedeutet doch nur, dass sobald aus dem LAN Traffic zu einer IP des Tunnels geleitet wird, der VPN versucht wird aufzubauen.
"Start immediate" ist bei mir aktiv und heißt ja eigentlich, dass er sofort und immer die Verbindung versuchen soll aufzubauen.

[OPNFox]

Ok, ich habe es mir selbst beantwortet...
Ich habe vergessen, ESP, 500 und 4500 auf der WAN Seite freizugeben.
Daher funktionierte es nur, wenn man die jeweilige Firewall aktiv aufforderte mit der anderen Seite zu kommunizieren, da sie dann wohl auf die WAN Seite horcht und ohne die Freigabe nicht.

Zumindest ist das meine aktuelle Vermutung und der Tunnel baute sich aktuell einmal alleine auf.

[schnipp]

[...]
"Start on traffic" bedeutet doch nur, dass sobald aus dem LAN Traffic zu einer IP des Tunnels geleitet wird, der VPN versucht wird aufzubauen.
"Start immediate" ist bei mir aktiv und heißt ja eigentlich, dass er sofort und immer die Verbindung versuchen soll aufzubauen.

Es ist nicht so, wie die Bezeichner suggerieren mögen. ,,Start immediate" startet eine Verbindung unmittelbar mit Start des VPN-Daemons. Beendete oder abgebrochene Verbindungen werden seitens des Daemons nicht eigenmächtig wieder aufgebaut. Den automatischen Wiederaufbau erledigt nur ,,Start immediate".

Ok, ich habe es mir selbst beantwortet...
Ich habe vergessen, ESP, 500 und 4500 auf der WAN Seite freizugeben.

Diese eingehenden Firewall-Regeln sind nicht dafür verantwortlich, dass der VPN-Daemon eine abgebrochene VPN-Verbindung selbst nicht wieder aufbaut. Er kann ohne diese Regeln nur nicht auf eingehende Verbindungsanfragen reagieren.