Question

The rutx09's and rutx50's seem to have the same issue with regards to IPSEC VPN tunnels. Sometimes (not always) the rutx fails to setup all child SA's. A restart of the ipsec services fixes this. I found a similar case in the forums, but the given fix "Compatibility mode=on" did not fix it. Remote endpoint is a Fortigate firewall.

See cli output:

root@W01-RTR01:~# ipsec status

Security Associations (1 up, 0 connecting):

CustX-CustX_c[2]: ESTABLISHED 11 minutes ago, 10.178.237.3[W01-RTR01]...1.2.3.4[WHZ-FW02]

CustX-CustX_c_1{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c45cd9d0_i ff6a7896_o

CustX-CustX_c_1{1}:  10.100.1.254/32 === 10.20.0.0/16

root@W01-RTR01:~# ipsec restart

Stopping strongSwan IPsec...

Starting strongSwan 5.9.2 IPsec [starter]...

root@W01-RTR01:~# ipsec status

Security Associations (1 up, 0 connecting):

CustX-CustX_c[1]: ESTABLISHED 3 seconds ago, 10.178.237.3[W01-RTR01]...1.2.3.4[WHZ-FW02]

CustX-CustX_c{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c0aa5aa1_i ff6a78a2_o

CustX-CustX_c{1}:  10.100.1.254/32 === 192.168.222.0/24

CustX-CustX_c_1{2}: INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: c97ee7fe_i ff6a78a3_o

CustX-CustX_c_1{2}:  10.100.1.254/32 === 10.20.0.0/16

root@W01-RTR01:~#

I've attached the troubleshoot file.

Answer 1

Hello,

With IPSec, the child SAs are typically not persistent and are taken down when there is no traffic. However, phase 1 SA remains established.

Could you try changing the IPSec mode from 'start' to 'route'? This adjustment should enable IPSec to rebuild a child SA when there is user traffic.

Please let me know if the child SA reestablishes when there is user traffic that is relevant to the SA/network.

Kind Regards,

Andzej

Comments

Thanks I will make the change and report back.

---

Hi Andzej,

I've just read the documentation on that parameter:

auto = ignore | add | route | start

what operation, if any, should be done automatically at IPsec startup. add loads a connection without

starting it. route loads a connection and installs kernel traps. If traffic is detected between

leftsubnet and rightsubnet, a connection is established. start loads a connection and brings

it up immediately. ignore ignores the connection. This is equal to deleting a connection from the config

file. Relevant only locally, other end need not agree on it.

So based on that, "start" should be the right one to my opinion. The Rutx is behind ISP nat, so it will always have to initiate the VPN connection towards HQ. (Monitoring) traffic is initiated from HQ towards the Rutx loopback interface (through the VPN). Was there a reason in the troubleshoot file why one of the two child SA's was brought down? And why was it not reconnected after disruption? I've had this issue for months and couldn't figure out why it "sometimes" fails on this part. 

---

Hello,

The troubleshoot file indicates that only one child SA is present and there isn't much additional information available. It doesn't provide any details about the reason for the deletion of the second child SA. However, it can be observed that after manually restarting IPSec, two SAs are established. Is it possible that there is no SA because there is no relevant traffic?

Would it be possible to obtain a troubleshoot file once the router has been running for a while?

Also, could you try setting the Dead Peer Detection (DPD) action to restart?

To avoid IPSec errors visible in the logs, I would suggest restarting IPSec with:

•  /etc/init.d/ipsec restart



Kind Regards,

Andzej

---

Hi Andzej,

There is monitoring traffic from HQ to the Rutx loopback interface (that is the child SA that goes down). So there is traffic (every minute), but when it's down, there is no traffic since the monitoring system can no longer reach the Rutx loopback interface. I will create a troubleshoot file when it happens again, might be another router, but the issue is identical. DPD is already set to "restart".

Regards,

Leon

---

Hi,

Sure. Let me know once you have a new troubleshoot file available.

Kind Regards,

---

I just run into the issue (on another router) when I was in an Anydesk session with your collegue (DaumantasG) for the SNMPD issue.

We've adjusted the P1 (24h) and P2 (12h) timer. The missing child sa came online after that. Will monitor how it will pan out with these settings. 

---

Hi,

Thank you for the update. So the issue was caused by a mismatch in IKE lifetimes on the other device? I assume that the IKE lifetime on that device was set to a significantly higher value compared to the 1-hour and 3-hour lifetimes on the RUT router. Please let me know if adjusting the IKE lifetime has resolved the problem.

EDIT: Just noticed that you mentioned the lifetime. Let me know if everything is fine now.

Kind Regards,

Andzej

---

Hi Andzej,

I've made the change to all our routers and will have to wait for a couple of weeks. When the issue won't reoccur, I will update this thread.

Regards,

Leon