On 08/10/2014 03:09 PM, Reyk Floeter wrote: > Just try to increase the number of "v"s to get more info, for example, > iked -dvv or iked -dvvv to get packet dumps.
Thanks for the hint. That brought some progress. I've now switched back to -current and changed the client setup (I had been using the NetworkManager backend of the charon keying daemon, which caused the crashes, also on -current). Now iked does not crash anymore - I will still do the recompiling and backtracing, as this clearly should not happen. But I think it would make sense to first get a working setup. That said, the connection does still not succeed. After SA_INIT and IKE_AUTH everything seems fine, certificate gets authenticated, but then iked says it can't send the ike_auth packet back. Aug 12 11:02:47 tunnel iked[26844]: sa_stateok: VALID flags 0x1f, require 0x1f cert,certvalid,auth,authvalid,sa ug 12 11:02:47 tunnel iked[26844]: ikev2_next_payload: length 22 nextpayload CERT Aug 12 11:02:47 tunnel iked[26844]: ikev2_next_payload: length 1520 nextpayload AUTH Aug 12 11:02:47 tunnel iked[26844]: ikev2_next_payload: length 264 nextpayload CP Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa_getspi: message: Operation not supported ... Strange ... what is not supported? ... Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length 24 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: count 1 length 16 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: start 10.x.y.z end 10.x.y.z Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00 length 8 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: count 1 length 0 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: type <UNKNOWN:0> protoid 0 length 0 startport 0 endport 65535 Aug 12 11:02:47 tunnel iked[26844]: ikev2_msg_send: IKE_AUTH response from 10.x.y.z:4500 to A.B.C.D:4500 msgid 1, 1996 bytes, NAT-T Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa_add: update spi 0xf82bfb58 Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa: udpencap port 4500 Aug 12 11:02:47 tunnel iked[26844]: ikev2_childsa_enable: loaded CHILD SA spi 0xf82bfb58 Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa_add: add spi 0xcdac6edf Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa: udpencap port 4500 Aug 12 11:02:47 tunnel iked[26844]: ikev2_childsa_enable: loaded CHILD SA spi 0xcdac6edf Aug 12 11:02:47 tunnel iked[26844]: pfkey_flow: unsupported address family 0 Aug 12 11:02:47 tunnel iked[26844]: ikev2_childsa_enable: failed to load flow Aug 12 11:02:47 tunnel iked[26844]: ikev2_dispatch_cert: failed to send ike auth Does anybody see what's going wrong here? It does then send out a packet, but on the client side this triggers an error: initiating IKE_SA xfertunnel[1] to E.F.G.H generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] sending packet: from 192.168.1.x[500] to E.F.G.H[500] (1204 bytes) received packet: from E.F.G.H[500] to 192.168.1.x[500] (457 bytes) parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ] local host is behind NAT, sending keep alives remote host is behind NAT received cert request for <CA> sending cert request for <CA> authentication of 'j...@doe.com' (myself) with RSA signature successful sending end entity cert <johndoe DN> establishing CHILD_SA xfertunnel generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH CPRQ(ADDR DNS DNS) N(USE_TRANSP) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(EAP_ONLY) ] sending packet: from 192.168.1.x[4500] to E.F.G.H[4500] (2236 bytes) received packet: from E.F.G.H[4500] to 192.168.1.x[4500] (1996 bytes) TS_RESPONDER verification failed could not decrypt payloads message verification failed IKE_AUTH response with message ID 1 processing failed Any more ideas? Thx /markus
