Issue #2414
Charon sometimes doesn't react to stroke command
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 almost 5 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 almost 5 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 almost 5 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 almost 5 years ago
It is the same issue like #1453. So far not fixed in official release.
#5 Updated by Tobias Brunner almost 5 years ago
- Is duplicate of Bug #1453: Starter is getting stuck handling ipsec reload added
#6 Updated by Tobias Brunner almost 5 years ago
- Is duplicate of deleted (Bug #1453: Starter is getting stuck handling ipsec reload )
#7 Updated by Tobias Brunner almost 5 years ago
- Related to Bug #1453: Starter is getting stuck handling ipsec reload added
#8 Updated by Jiri Zendulka almost 5 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 almost 5 years ago
- Category set to libstrongswan
- Status changed from Feedback to Closed
- Resolution set to Duplicate