Bug #408
strongswan dies due to closeaction=restart
Start date:
09.09.2013
Due date:
Estimated time:
Affected version:
5.1.0
Resolution:
Fixed
Description
On my box, charon is dieing. Sometimes with
Sep 09 21:55:29 vms.thermi ipsec[228]: dumping 2 stack frame addresses: Sep 09 21:55:29 vms.thermi ipsec[228]: /usr/lib/libpthread.so.0 @ 0x7f273ec96000 [0x7f273eca5870] Sep 09 21:55:29 vms.thermi ipsec[228]: -> sigaction.c:? Sep 09 21:55:29 vms.thermi ipsec[228]: [0x7f2704000078] Sep 09 21:55:29 vms.thermi ipsec[228]: charon has died -- restart scheduled (5sec) Sep 09 21:55:29 vms.thermi ipsec_starter[228]: charon has died -- restart scheduled (5sec) Sep 09 21:55:34 vms.thermi ipsec[228]: charon (9167) started after 80 ms Sep 09 21:55:34 vms.thermi ipsec_starter[228]: charon (9167) started after 80 ms
And sometimes just with:
Sep 09 22:16:55 vms.thermi ipsec_starter[18431]: charon has died -- restart scheduled (5sec) Sep 09 22:17:00 vms.thermi ipsec_starter[18431]: charon (21175) started after 120 ms
Linux kernel version is 3.10.10-1-ARCH and the distribution on both machines is Arch Linux.
The client's and the server's logs are attached to the report.
How-to-cause:
(as client)
# ipsec start # ipsec up server # watch it trying to negotiate and crash
I could reproduce the issue 100% of times.
It also crashes with "esp=aes256-sha256-ecp521!", which doesn't seem to be supported right now.
client:
# ipsec up server initiating IKE_SA server[1] to 192.168.178.48 generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V ] sending packet: from 192.168.178.43[500] to 192.168.178.48[500] (328 bytes) received packet: from 192.168.178.48[500] to 192.168.178.43[500] (381 bytes) parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ] faking NAT situation to enforce UDP encapsulation received cert request for "C=DE, ST=Baden-W??rttemberg, O=ThermiCorp, OU=ServerCA Layer 2, CN=ThermiCorp ServerCA Layer 2" received cert request for "C=DE, ST=Baden-W??rttemberg, O=ThermiCorp, OU=UserCA, CN=ThermiCorp UserCA Level 2" received cert request for "C=DE, ST=Baden-W??rttemberg, L=Haslach, O=ThermiCorp, OU=Root CA, CN=ThermiCorp Root CA, E=noel.kuntze@googlemail.com" sending cert request for "C=DE, ST=Baden-W??rttemberg, O=ThermiCorp, OU=UserCA, CN=ThermiCorp UserCA Level 2" sending cert request for "C=DE, ST=Baden-W??rttemberg, L=Haslach, O=ThermiCorp, OU=Root CA, CN=ThermiCorp Root CA, E=noel.kuntze@googlemail.com" sending cert request for "C=DE, ST=Baden-W??rttemberg, O=ThermiCorp, OU=ServerCA Layer 2, CN=ThermiCorp ServerCA Layer 2" authentication of 'nfs-client' (myself) with pre-shared key establishing CHILD_SA server generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) ] sending packet: from 192.168.178.43[4500] to 192.168.178.48[4500] (336 bytes) received packet: from 192.168.178.48[4500] to 192.168.178.43[4500] (240 bytes) parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(AUTH_LFT) ] authentication of 'nfs-server' with pre-shared key successful IKE_SA server[1] established between 192.168.178.43[nfs-client]...192.168.178.48[nfs-server] scheduling reauthentication in 9866s maximum IKE_SA lifetime 10406s can't install route for 192.168.178.43/32 === 192.168.178.48/32 out, conflicts with IKE traffic unable to install IPsec policies (SPD) in kernel failed to establish CHILD_SA, keeping IKE_SA received AUTH_LIFETIME of 3369s, scheduling reauthentication in 2829s sending DELETE for ESP CHILD_SA with SPI 59fa3d8f generating INFORMATIONAL request 2 [ D ] sending packet: from 192.168.178.43[4500] to 192.168.178.48[4500] (80 bytes) retransmit 1 of request with message ID 2 sending packet: from 192.168.178.43[4500] to 192.168.178.48[4500] (80 bytes) retransmit 2 of request with message ID 2 sending packet: from 192.168.178.43[4500] to 192.168.178.48[4500] (80 bytes) ^C
ipsec.conf:
config setup
# strictcrlpolicy=yes
# uniqueids = no
conn %default
leftupdown=/usr/lib/strongswan/sudo_updown
ca home
auto=add
cacert=vpn-ca.pem
ca server
auto=add
cacert=serverca.pem
ca user
auto=add
cacert=userca.pem
conn server
left=192.168.178.43
leftid=nfs-client
leftauth=psk
ike=aes256-sha256-ecp521!
esp=aes256-sha256-modp2048!
keyexchange=ikev2
rightauth=psk
right=192.168.178.48
rightid=nfs-server
auto=add
mobike=no
strongswan.conf:
# strongswan.conf - strongSwan configuration file
charon {
threads = 16
send_vendor_id = yes
syslog {
daemon {
default=3
enc=1
job=1
asn=1
cfg=1
}
}
filelog {
/var/log/charon.log {
default=3
enc=1
job=1
asn=1
cfg=1
}
}
}
libstrongswan {
dh_exponent_ansi_x9_42 = no
}
server:
journal output:
Sep 09 22:12:31 vms.thermi ipsec_starter[18422]: Starting strongSwan 5.1.0 IPsec [starter]... Sep 09 22:12:31 vms.thermi ipsec_starter[18431]: charon (18432) started after 80 ms Sep 09 22:16:55 vms.thermi ipsec_starter[18431]: charon has died -- restart scheduled (5sec) Sep 09 22:17:00 vms.thermi ipsec_starter[18431]: charon (21175) started after 120 ms
ipsec.conf:
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
uniqueids=replace
strictcrlpolicy=no
ca home
auto=add
cacert=vpn-ca.pem
ca server
auto=add
cacert=serverca.pem
ca user
auto=add
cacert=userca.pem
conn %default
ikelifetime=60m
marginbytes=3000000000
marginpackets=150000
inactivity=0s
keylife=20m
rekeymargin=3m
keyingtries=3
tfc=%mtu
dpdaction=restart
dpddelay=10
dpdtimeout=60
compress=yes
left=192.168.178.48
leftupdown=/usr/lib/strongswan/sudo_updown
( five connections redacted )
conn nfs
leftauth=psk
left=192.168.178.48
leftid=nfs-server
ike=aes256-sha256-ecp521!
esp=aes256-sha256-modp2048!
rightid=nfs-client
right=%any
rightauth=psk
auto=add
closeaction=restart
strongswan.conf:
# strongswan.conf - strongSwan configuration file
starter {
load_warning = no
}
charon {
load=charon test-vectors curl random nonce x509 revocation constraints pubkey pkcs1 pem openssl af-alg gmp xcbc cmac hmac fips-pfr ccm attr kernel-netlink socket-default farp stroke updown eap-identity eap-gtc eap-mschapv2 eap-radius xauth-generic xauth-eap unity
dns1=192.168.178.48
dns2=192.168.178.6
cisco_unity=yes
dos_protection = yes
threads = 32
user=strongswan
retry_initiate_interval = 3
user=strongswan
group=strongswan
# syslog {
# daemon {
# enc=-1
# cfg=1
# asn=1
# net=0
# ike=0
# }
# }
filelog {
/var/log/charon.log {
default = 3
enc=2
cfg=3
asn=3
append=no
ike_name=no
}
/var/log/charon_compact.log {
default = 3
enc = 0
cfg = 2
asn = 1
job = 1
append=no
ike_name=no
}
/var/log/charon_debug.log {
default=3
}
}
}
libstrongswan {
dh_exponent_ansi_x9_42 = yes
crypto_test {
bench=no
bench_size=1500
bench_time=50
on_add=no
required=no
}
}
History
#1 Updated by Tobias Brunner about 12 years ago
- Description updated (diff)
- Status changed from New to Resolved
- Assignee set to Tobias Brunner
- Target version set to 5.1.1
- Resolution set to Fixed
I think this is not due to the algorithms you chose but rather to a regression in 5.1.0 that broke closeaction=restart, which was already fixed with commit:e42ab08a73.
#2 Updated by Tobias Brunner about 12 years ago
- Status changed from Resolved to Closed
#3 Updated by Tobias Brunner almost 12 years ago
- Subject changed from strongswan dies with certain algorithms to strongswan dies due to closeaction=restart