On 08/12/2014 07:19 PM, Reyk Floeter wrote: > Another reason for AF 0 could be the use of the keyword "any" in your > iked.conf. I thought we fixed that before to inherit the AF from the > peer, but try to use "0.0.0.0/0" instead of "any" for IPv4 and > something like "::/0" for IPv6. > > Reyk >
Yes, that was indeed the cause. Replacing every occurance of "any" with 0.0.0.0/0 finally allowed the flow to be set up! Thank you very much !!! But still, no joy ... :-[ iked now authenticates the ufqdn and sends it its assigned ip address. Then it sends TSi and TSr, but chooses its own internal address as TSi: Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_cp: type REPLY length 8 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_cp: INTERNAL_IP4_ADDRESS 0x0001 length 4 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload SA nextpayload TSi critical 0x00 length 44 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_sa: more 0 reserved 0 length 40 proposal #1 protoid ESP spisize 4 xforms 3 spi 0x18f70837 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 0 reserved 0 length 8 type ESN id NONE Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length 24 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: count 1 length 16 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: start 192.168.10.Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_cp: type REPLY length 8 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_cp: INTERNAL_IP4_ADDRESS 0x0001 length 4 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload SA nextpayload TSi critical 0x00 length 44 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_sa: more 0 reserved 0 length 40 proposal #1 protoid ESP spisize 4 xforms 3 spi 0x18f70837 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 0 reserved 0 length 8 type ESN id NONE Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length 24 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: count 1 length 16 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: start 10.x.y.z end 10.x.y.z Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00 length 24 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: count 1 length 16 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: start 0.0.0.0 end 255.255.255.255 Aug 12 20:40:52 tunnel iked[6305]: ikev2_msg_send: IKE_AUTH response from 192.168.10.30:4500 to 80.219.68.219:4500 msgid 1, 1980 bytes, NAT-T 30 end 192.168.10.30 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00 length 24 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: count 1 length 16 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: start 0.0.0.0 end 255.255.255.255 Aug 12 20:40:52 tunnel iked[6305]: ikev2_msg_send: IKE_AUTH response from 10.x.y.z:4500 to A.B.C.D:4500 msgid 1, 1980 bytes, NAT-T Again, is not the TSi the client's address? Why would iked send its own private address? Is the problem that I am trying to assign addresses from the same internal network that the VPN GW is in? The strongswan logs seem to match this: Aug 12 20:40:52 slimtoo charon: 10[IKE] IKE_SA xfertunnel[1] state change: CONNECTING => ESTABLISHED Aug 12 20:40:52 slimtoo charon: 10[IKE] scheduling reauthentication in 86110s Aug 12 20:40:52 slimtoo charon: 10[IKE] maximum IKE_SA lifetime 86290s Aug 12 20:40:52 slimtoo charon: 10[IKE] processing INTERNAL_IP4_ADDRESS attribute Aug 12 20:40:52 slimtoo charon: 10[KNL] 192.168.1.x is on interface wlan0 Aug 12 20:40:52 slimtoo charon: 10[IKE] installing new virtual IP 10.a.b.c Aug 12 20:40:52 slimtoo charon: 10[KNL] virtual IP 10.a.b.c installed on wlan0 Aug 12 20:40:52 slimtoo charon: 10[CFG] selecting proposal: Aug 12 20:40:52 slimtoo charon: 10[CFG] proposal matches Aug 12 20:40:52 slimtoo charon: 10[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ Aug 12 20:40:52 slimtoo charon: 10[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ Aug 12 20:40:52 slimtoo charon: 10[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ Aug 12 20:40:52 slimtoo charon: 10[CFG] selecting traffic selectors for us: Aug 12 20:40:52 slimtoo charon: 10[CFG] config: 10.a.b.c/32, received: 10.x.y.z/32 => no match Aug 12 20:40:52 slimtoo charon: 10[CFG] selecting traffic selectors for other: Aug 12 20:40:52 slimtoo charon: 10[CFG] config: A.B.C.D/32, received: 0.0.0.0/0 => match: A.B.C.D/32 Aug 12 20:40:52 slimtoo charon: 10[IKE] no acceptable traffic selectors found Aug 12 20:40:52 slimtoo charon: 10[IKE] failed to establish CHILD_SA, keeping IKE_SA Feels quite close now ... thx /markus
