On 08/12/2014 05:39 PM, Markus Wernig wrote: > But really, I think this is the problem: > Aug 12 16:56:18 tunnel iked[22215]: ikev2_childsa_enable: loaded CHILD > SA spi 0xcb320247 > Aug 12 16:56:18 tunnel iked[22215]: pfkey_flow: unsupported address family 0 > Aug 12 16:56:18 tunnel iked[22215]: ikev2_childsa_enable: failed to load > flow > Aug 12 16:56:18 tunnel iked[22215]: ikev2_dispatch_cert: failed to send > ike auth > > It seems that the flow that comes from &sa->sa_flows in > ikev2.c::ikev2_childsa_enable does not have its AF set. How could this > happen? >
Could this be the reason? Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length 24 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: count 1 length 16 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: start 10.x.y.z end 10.x.y.z Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00 length 8 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: count 1 length 0 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: type <UNKNOWN:0> protoid 0 length 0 startport 0 endport 65535 Should not the TSi contain the IP of the Client? In the log above it appears that it contains the IP of the VPN GW. And then TSr is of an unknown type? Is strongswan sending something wrong here? thx /markus
