IPsec site-to-site VPN loses connection after upgrade to 22.1.8

[Paweł]

Hi everyone.

I've had 3 site-to-site VPN connections via IPsec configured for years. There have never been the slightest connection problems.
After upgrading to version 22.1.8, all connections disconnect every few minutes. This is a very serious problem because the functioning of the university depends on the efficient connection between its branches. To reconnect I have to manually restart the service or connection.

Does anyone know the solution to the problem?

[_Alchemist_]

The fastest way would probably be to revert back to 22.1.7 for the time being.

Do you see any errors in "VPN --> IPSec --> Log File" ?

[Paweł]

I found something: Lifetime is 28,800 seconds. The error message says the maximum value is 28,188 seconds. However, this does not explain why connections are dropped and not renewed automatically.

[DarthKurt]

All of my IPSec and OpenVPN tunnels all went down after 22.1.8
I see that the update created a new OPT1 interface, but I was unsure what to do with it.
I tried a few things but nothing worked, so I reverted back to the previous snapshot.

[pauldy]

I ran into an ipsec issue too after the update.  My problem was slightly different in that I couldn't negotiate a protocol for the IKE.  After poking around I saved a setting and noticed it went from showing AES (256 bits) to AES256 in the proposal, so I went resaved all the configs they all changed to AES256 and then they started working as expected.

[mic]

Hi,

I also have the same problem. The IPSec Tunnel goes down after some time of inactivity and I have to restart the service to get the IPSec Tunnel to work again. In Phase 1 Lifetime it is 28800 while in Phase 2 (Mode: Route-based) it is 3600.
Could someone help me, please?

Thank you

[bugzptr]

I adjusted my Phase 1 Lifetime to 28000 on both sides of the connection.

This seems to have resolved it. I've only implemented this on one of my tunnels, the ones I haven't modified remain disconnected.

[Paweł]

I rectified the problem by adding a "Restart IPsec service" action to the cron.
The restart takes about 3 seconds. Such a break is not a problem.
I hope that the problem will be permanently resolved after the next update.

[Patrick M. Hausen]

I also have the same problem. The IPSec Tunnel goes down after some time of inactivity and I have to restart the service to get the IPSec Tunnel to work again. In Phase 1 Lifetime it is 28800 while in Phase 2 (Mode: Route-based) it is 3600.

You might want to try setting the "Close Action" parameter to "Restart". I introduced that into the UI specifically for tunnels going down for unknown reasons. Turned out remote site was sending a close request which leads to a regular tear-down. With this setting and all tunnels set to on-demand our site-to-site connections have been rock solid.

HTH,
Patrick

[mic]

Hi,

I tried the solution suggested by bugzptr but with no luck. Now I try what pmhausen suggested and keep you informed. Below you can see my logs

Code: [Select]

2022-05-30T09:55:06 Informational charon 10[ENC] <con1|2> parsed INFORMATIONAL response 856 [ D ]
2022-05-30T09:55:06 Informational charon 10[NET] <con1|2> received packet: from OPNSENSE_REMOTE_PUBLIC_IP[500] to OPNSENSE_LOCAL_PUBLIC_IP[500] (69 bytes)
2022-05-30T09:55:06 Informational charon 10[NET] <con1|2> sending packet: from OPNSENSE_LOCAL_PUBLIC_IP[500] to OPNSENSE_REMOTE_PUBLIC_IP[500] (69 bytes)
2022-05-30T09:55:06 Informational charon 10[ENC] <con1|2> generating INFORMATIONAL request 856 [ D ]
2022-05-30T09:55:06 Informational charon 10[IKE] <con1|2> sending DELETE for ESP CHILD_SA with SPI c439b93b
2022-05-30T09:55:06 Informational charon 10[IKE] <con1|2> failed to establish CHILD_SA, keeping IKE_SA
2022-05-30T09:55:06 Informational charon 10[IKE] <con1|2> unable to install inbound and outbound IPsec SA (SAD) in kernel
2022-05-30T09:55:05 Informational charon 10[CFG] <con1|2> selected proposal: ESP:AES_GCM_16_256/MODP_8192/NO_EXT_SEQ
2022-05-30T09:55:05 Informational charon 10[IKE] <con1|2> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
2022-05-30T09:55:05 Informational charon 10[ENC] <con1|2> parsed CREATE_CHILD_SA response 855 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
2022-05-30T09:55:05 Informational charon 10[NET] <con1|2> received packet: from OPNSENSE_REMOTE_PUBLIC_IP[500] to OPNSENSE_LOCAL_PUBLIC_IP[500] (1225 bytes)
2022-05-30T09:55:05 Informational charon 10[NET] <con1|2> sending packet: from OPNSENSE_LOCAL_PUBLIC_IP[500] to OPNSENSE_REMOTE_PUBLIC_IP[500] (1225 bytes)
2022-05-30T09:55:05 Informational charon 10[ENC] <con1|2> generating CREATE_CHILD_SA request 855 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
2022-05-30T09:55:04 Informational charon 10[IKE] <con1|2> establishing CHILD_SA con1{499} reqid 1
2022-05-30T09:55:04 Informational charon 10[KNL] creating acquire job for policy OPNSENSE_LOCAL_PUBLIC_IP/32 === OPNSENSE_REMOTE_PUBLIC_IP/32 with reqid {1}
2022-05-30T09:55:03 Informational charon 10[NET] <con1|2> sending packet: from OPNSENSE_LOCAL_PUBLIC_IP[500] to OPNSENSE_REMOTE_PUBLIC_IP[500] (65 bytes)
2022-05-30T09:55:03 Informational charon 10[ENC] <con1|2> generating CREATE_CHILD_SA response 304 [ N(NO_PROP) ]
2022-05-30T09:55:03 Informational charon 10[IKE] <con1|2> failed to establish CHILD_SA, keeping IKE_SA
2022-05-30T09:55:03 Informational charon 10[IKE] <con1|2> unable to install inbound and outbound IPsec SA (SAD) in kernel

Thank you

[mic]

Hi,

I tried the solution suggested by bugzptr but it didn't work. After about 15-20 minutes of incantivity the IPSec Tunnel goes down. Instead if there is traffic in the Tunnel (infinite ping) the link doesn't go down...   

Thank you

[Patrick M. Hausen]

That's expected with on-demand setting. The question is if it does come up immediately as soon as there is traffic.

[mic]

No, it doesn't come up

[joelmnz]

Looking at your log file it seems the Phase 1 is standing up fine. It is trying to initiate the Phase 2 (CHILD_SA) and is failing for some reason.

Personally, I'd start by looking at the settings for the Phase 2 tunnel and comparing the settings on both ends of the connection to make sure they match EXACTLY.... mismatched lifetimes can cause issues with one end of the connection terminating. IPSEC is very intolerant of mismatched settings.

Personally I make the lifetimes for Phase 2 half the duration of Phase 1. So if Phase 1 is 28800, then Phase 2 is 14400.

Changing the log settings to debug can show more detail about what might be going on with the CHILD_SA as well.

[mic]

Hi,

the configurations on both ends are exactly the same. If I restart the service on the local OPNsense (22.1.8_1) the IPSec Tunnel goes up and everything works perfectly for a certain period of time. If I generate traffic in the Tunnel (infinite ping versus a host in the remote network), the tunnel doesn't go down. It goes down after a period of time if there isn't traffic in the tunnel.
This issue is started when I updated local OPNsense to 22.1.8_1. The remote version of OPNsense is 22.1.2_1

I attach Phase 1 and Phase 2 configuration of the local OPNSense. They are exactly the same on remote OPNsense, except for "Remote Gateway" in Phase 1 and "Local Address" and "Remote Address" in Phase 2 that are inverted...

Thank you