Issue #2414: Charon sometimes doesn't react to stroke command - strongSwan

Issue #2414

Charon sometimes doesn't react to stroke command

Added by Jiri Zendulka about 3 years ago. Updated about 3 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Category:

libstrongswan

Affected version:

5.5.3

Resolution:

Duplicate

Description

We are runnig IPsec on router with 2 Mobile WAN interfaces. Sometimes during switching default interface (lost mobile connection on one of interfaces) charon freezes and doesn't react to stroke cmd.

To demonstrate this state I cleaned all connections from ipsec.conf and I run stroke rereadall. But stroke statussall still contains old connections:

$ cat /etc/ipsec.d/ipsec.conf
config setup
 charondebug=dmn 1, mgr 1, ike 1, chd 1, job 1, cfg 1, knl 1, net 1, asn 1, enc 1, lib 1, esp 1, tls 1, tnc 1, imc 1, imv 1, pts 1

$ /usr/libexec/ipsec/stroke rereadall

IPsec status still contains old IP address which is not available anymore.

$ /usr/libexec/ipsec/stroke  statusall
Status of IKE charon daemon (weakSwan 5.5.3, Linux 3.12.10+, armv7l):
  uptime: 10 days, since Aug 17 15:41:06 2017
  malloc: sbrk 532480, mmap 0, used 149456, free 383024
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 0
  loaded plugins: charon nonce pem openssl kernel-netlink socket-default stroke updown
Listening IP addresses:
  172.25.255.241
  10.85.0.128
Connections:
      ipsec1:  10.85.0.45...172.27.0.65  IKEv2, dpddelay=10s
      ipsec1:   local:  [O=checkpoint-mgmt1..x2r4of, OU=users, CN=6600148] uses public key authentication
      ipsec1:    cert:  "O=checkpoint-mgmt1..x2r4of, OU=users, CN=6600148" 
      ipsec1:   remote: [172.27.0.65] uses public key authentication
      ipsec1:    cert:  "O=checkpoint-mgmt1..x2r4of, CN=espoo-fw-cluster VPN Certificate" 
      ipsec1:   child:  172.25.255.240/28 === 132.171.38.0/26 172.27.0.0/27 TUNNEL, dpdaction=restart
      ipsec2:  10.85.0.45...172.27.0.129  IKEv2, dpddelay=10s
      ipsec2:   local:  [O=checkpoint-mgmt1..x2r4of, OU=users, CN=6600148] uses public key authentication
      ipsec2:    cert:  "O=checkpoint-mgmt1..x2r4of, OU=users, CN=6600148" 
      ipsec2:   remote: [172.27.0.129] uses public key authentication
      ipsec2:    cert:  "O=checkpoint-mgmt1..x2r4of, CN=lohja-fw-cluster VPN Certificate" 
      ipsec2:   child:  172.25.255.240/28 === 132.171.38.192/26 172.27.0.0/27 TUNNEL, dpdaction=restart
Security Associations (0 up, 0 connecting):
  none

Only "kill charon" helps in this state.

Related issues

History

#1 Updated by Tobias Brunner about 3 years ago

Status changed from New to Feedback

We are runnig IPsec on router with 2 Mobile WAN interfaces. Sometimes during switching default interface (lost mobile connection on one of interfaces) charon freezes and doesn't react to stroke cmd.

If that happens try attaching GDB to charon and get backtraces for all the threads (thread apply all bt).

To demonstrate this state I cleaned all connections from ipsec.conf and I run stroke rereadall. But stroke statussall still contains old connections:

Why would you expect anything else? ipsec.conf is read by starter, not stroke. And IpsecCommand rereadall only reads credentials again.

And how is that related to the above?

IPsec status still contains old IP address which is not available anymore.

You mean in the Listening IP addresses section? These are retrieved via kernel interface and updated when the kernel sends events regarding interfaces and addresses. Check the log for details.

#2 Updated by Jiri Zendulka about 3 years ago

Tobias Brunner wrote:

IPsec status still contains old IP address which is not available anymore.

You mean in the Listening IP addresses section? These are retrieved via kernel interface and updated when the kernel sends events regarding interfaces and addresses. Check the log for details.

Yes, I mean listening adresses and connections. Listening addresses are updated. But in connections section the old IP 10.85.0.45 still persists...there is no update. Normally source IP adress is always present in listening addresses section.

#3 Updated by Jiri Zendulka about 3 years ago

Jiri Zendulka wrote:

Tobias Brunner wrote:

IPsec status still contains old IP address which is not available anymore.

You mean in the Listening IP addresses section? These are retrieved via kernel interface and updated when the kernel sends events regarding interfaces and addresses. Check the log for details.

Yes, I mean listening adresses and connections. Listening addresses are updated. But in connections section the old IP 10.85.0.45 still persists...there is no update. Normally source IP adress is always present in listening addresses section.

...in case that in ipsec.conf is no conn section present then I expect no entry in section Connections after stroke rereadall. But it does not. Or does work stroke rereadall in different way?