Project

General

Profile

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

Related to Bug #1453: Starter is getting stuck handling ipsec reload Closed

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?

#4 Updated by Jiri Zendulka about 3 years ago

It is the same issue like #1453. So far not fixed in official release.

#5 Updated by Tobias Brunner about 3 years ago

  • Is duplicate of Bug #1453: Starter is getting stuck handling ipsec reload added

#6 Updated by Tobias Brunner about 3 years ago

  • Is duplicate of deleted (Bug #1453: Starter is getting stuck handling ipsec reload )

#7 Updated by Tobias Brunner about 3 years ago

  • Related to Bug #1453: Starter is getting stuck handling ipsec reload added

#8 Updated by Jiri Zendulka about 3 years ago

Jiri Zendulka wrote:

It is the same issue like #1453. So far not fixed in official release.

Fix https://git.strongswan.org/?p=strongswan.git;a=commit;h=6572d3d5ad9b317bca23d9e1ce1d5003ee239bbf works fine. You can close the issue. Many thanks.

#9 Updated by Tobias Brunner about 3 years ago

  • Category set to libstrongswan
  • Status changed from Feedback to Closed
  • Resolution set to Duplicate

Also available in: Atom PDF