[strongSwan] strongswan on embedded system hangs while trying to establish CHILD_SA
Lusian, Robert
Robert.Lusian at itron.com
Fri Sep 9 16:39:57 CEST 2016
Hello!
I am trying to use Strongswan to connect an embedded system board to a Cisco CGR 1000 router.
The connection partially succeeds, but when strongswan tries to establish a CHILD_SA strongswan hangs.
If I use the same configuration and addressing scheme with strongSwan 5.3.5 on an Ubuntu 16.04 LTS x64 system,
the connection is successful.
I am using Strongswan 5.5.0 compiled for a Timesys embedded system running an ARM CPU.
The linux kernel version is 3.14.26-ts-armv7l. I suspect that there is some resource that is missing or not set up
properly on the embedded system and would appreciate some pointers on where to look.
The logs are not being particularly helpful in this regard.
The configuration looks like this. I am using unique-local IPv6 addresses as the basis for the VPN.
conn rivaios6
left=FDFF:444:11:1:ff:1:1:10
leftsubnet=2620:444:11:100::/64
leftid=FDFF:444:11:1:ff:1:1:10
leftfirewall=yes
right=FDFF:444:11:1:ff:1:1:f
rightsubnet=2620:222:10:100::/64
rightid=FDFF:444:11:1:ff:1:1:f
auto=add
ike=aes128-sha1-modp1536
esp=aes128-sha1
keyexchange=ikev2
I am using PSKs for now.
FDFF:444:11:1:ff:1:1:10 : PSK "cisco"
FDFF:444:11:1:ff:1:1:f : PSK "cisco"
With this configuration and addressing scheme strongswan works fine on the Ubuntu system and I get this:
$ sudo ipsec up rivaios6
initiating IKE_SA rivaios6[1] to fdff:444:11:1:ff:1:1:f
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
sending packet: from fdff:444:11:1:ff:1:1:10[500] to fdff:444:11:1:ff:1:1:f[500] (1020 bytes)
received packet: from fdff:444:11:1:ff:1:1:f[500] to fdff:444:11:1:ff:1:1:10[500] (412 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No V V N(NATD_S_IP) N(NATD_D_IP) ]
received Cisco Delete Reason vendor ID
received unknown vendor ID: 46:4c:45:58:56:50:4e:2d:53:55:50:50:4f:52:54:45:44
authentication of 'fdff:444:11:1:ff:1:1:10' (myself) with pre-shared key
establishing CHILD_SA rivaios6
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_6_ADDR) N(EAP_ONLY) ]
sending packet: from fdff:444:11:1:ff:1:1:10[4500] to fdff:444:11:1:ff:1:1:f[4500] (460 bytes)
received packet: from fdff:444:11:1:ff:1:1:f[4500] to fdff:444:11:1:ff:1:1:10[4500] (316 bytes)
parsed IKE_AUTH response 1 [ V IDr AUTH SA TSi TSr N(SET_WINSIZE) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
authentication of 'fdff:444:11:1:ff:1:1:f' with pre-shared key successful
IKE_SA rivaios6[1] established between fdff:444:11:1:ff:1:1:10[fdff:444:11:1:ff:1:1:10]...fdff:444:11:1:ff:1:1:f[fdff:444:11:1:ff:1:1:f]
scheduling reauthentication in 86125s
maximum IKE_SA lifetime 86305s
received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
CHILD_SA rivaios6{1} established with SPIs c1339792_i 9265ffde_o and TS 2620:444:11:100::/64 === 2620:222:10:100::/64
connection 'rivaios6' established successfully
If I try this on the embedded system, strongswan hangs when trying to establish the CHILD_SA:
# ./ipsec up rivaios6
Riva1# ./ipsec up rivaios6
initiating IKE_SA rivaios6[1] to fdff:444:11:1:ff:1:1:f
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from fdff:444:11:1:ff:1:1:10[500] to fdff:444:11:1:ff:1:1:f[500] (604 bytes)
received packet: from fdff:444:11:1:ff:1:1:f[500] to fdff:444:11:1:ff:1:1:10[500] (412 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No V V N(NATD_S_IP) N(NATD_D_IP) ]
received Cisco Delete Reason vendor ID
received unknown vendor ID: 46:4c:45:58:56:50:4e:2d:53:55:50:50:4f:52:54:45:44
authentication of 'fdff:444:11:1:ff:1:1:10' (myself) with pre-shared key
establishing CHILD_SA rivaios6
(hangs)
The end of the strongswan log file looks like this:
...
2016-09-08T21:56:03.505 08[ENC] <rivaios6|1> received unknown vendor ID: 46:4c:45:58:56:50:4e:2d:53:55:50:5
2016-09-08T21:56:03.615 08[CFG] <rivaios6|1> selecting proposal:
2016-09-08T21:56:03.729 08[CFG] <rivaios6|1> proposal matches
2016-09-08T21:56:03.825 08[CFG] <rivaios6|1> received proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1
2016-09-08T21:56:03.932 08[CFG] <rivaios6|1> configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SH
2016-09-08T21:56:04.035 08[CFG] <rivaios6|1> selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/
2016-09-08T21:56:04.271 08[IKE] <rivaios6|1> reinitiating already active tasks
2016-09-08T21:56:04.361 08[IKE] <rivaios6|1> IKE_CERT_PRE task
2016-09-08T21:56:04.503 08[IKE] <rivaios6|1> IKE_AUTH task
2016-09-08T21:56:04.591 08[ENC] <rivaios6|1> added payload of type NOTIFY to message
2016-09-08T21:56:04.692 08[ENC] <rivaios6|1> added payload of type ID_RESPONDER to message
2016-09-08T21:56:04.799 08[ENC] <rivaios6|1> added payload of type ID_INITIATOR to message
2016-09-08T21:56:04.889 08[ENC] <rivaios6|1> added payload of type NOTIFY to message
2016-09-08T21:56:04.987 08[IKE] <rivaios6|1> authentication of 'fdff:444:11:1:ff:1:1:10' (myself) with pre-
2016-09-08T21:56:05.105 08[IKE] <rivaios6|1> successfully created shared key MAC
2016-09-08T21:56:05.195 08[ENC] <rivaios6|1> added payload of type AUTH to message
2016-09-08T21:56:05.284 08[IKE] <rivaios6|1> establishing CHILD_SA rivaios6
2016-09-08T21:56:05.414 08[CFG] <rivaios6|1> proposing traffic selectors for us:
2016-09-08T21:56:05.521 08[CFG] <rivaios6|1> 2620:444:11:100::/64
2016-09-08T21:56:05.621 08[CFG] <rivaios6|1> proposing traffic selectors for other:
2016-09-08T21:56:05.730 08[CFG] <rivaios6|1> 2620:222:10:100::/64
2016-09-08T21:56:05.825 08[CFG] <rivaios6|1> configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ,
2016-09-08T21:56:16.752 01[JOB] watched FD 15 ready to read
2016-09-08T21:56:16.836 01[JOB] watcher going to poll() 5 fds
2016-09-08T21:56:16.928 01[JOB] watcher got notification, rebuilding
2016-09-08T21:56:17.021 01[JOB] watcher going to poll() 5 fds
2016-09-08T21:56:17.140 01[JOB] watched FD 15 ready to read
2016-09-08T21:56:17.221 01[JOB] watcher going to poll() 5 fds
2016-09-08T21:56:17.303 01[JOB] watcher got notification, rebuilding
(repeats until you stop it)
Do you have any idea what is causing the problem? We probably don't have something set up right but if you could point us
In the right direction that would be helpful. Looking at the code it seems like we are trying to send the next message to the router
and something is going wrong with that.
I tried doing a level 3 log but for some reason the ipsec up command quits very early in the process when logging at that level.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160909/49b2ca0b/attachment-0001.html>
More information about the Users
mailing list