[strongSwan] cannot respond to IPsec SA request because no connection is known

[Micah Anderson]

Daniel Mentz
<danielml+mailinglists.strongswan at sent.com> writes:

> On 07/09/2011 10:44 PM, Micah Anderson wrote:
>> For some reason that i do not understand, I'm getting:
>>
>> Jul  9 22:37:41 kestrel pluto[3901]: "l2tp-psk"[2] 208.54.45.249:58920 #1: cannot respond to IPsec SA request because no connection is known for 198.252.153.38:4500[198.252.153.38]:17/1701...208.54.45.249:58920[26.164.21.104]:17/%any==={26.164.21.104/32}
>
>>
>> conn l2tp-psk
>>    authby=secret
>>    pfs=no
>>    compress=no
>>    rekey=no
>>    keyexchange=ikev1
>>    keyingtries=3
>>    type=transport
>>    leftprotoport=17/1701
>>    right=%any
>>    rightprotoport=17/%any
>>    auto=add
>
> You specified transport mode in your config, right? 

Yes, type=transport above.

>However, it looks like your peer wants to setup a connection using
>tunnel mode: It says
>
> "208.54.45.249:58920[26.164.21.104]:17/%any==={26.164.21.104/32}"
>
> which means that your peer is 208.54.45.249, and this peer wants to 
> secure traffic for the subnet 26.164.21.104/32. This won't work in 
> transport mode because in this mode both peers only secure their own 
> traffic.

Hmm, ok... I assumed that this was how it worked because it was doing
nat traversal. I just tried to change the configuration to use
'type=tunnel' and I also upgraded to strongswan 4.5.2, but:

Jul 15 06:31:07 kestrel pluto[14750]: "l2tp-psk"[2] 208.54.45.177:17010 #1: cannot respond to IPsec SA request because no connection is known for 198.252.153.38:4500[198.252.153.38]:17/1701...208.54.45.177:17010[26.163.197.237]:17/%any===26.163.197.237/32
Jul 15 06:31:07 kestrel pluto[14750]: "l2tp-psk"[2] 208.54.45.177:17010 #1: sending encrypted notification INVALID_ID_INFORMATION to 208.54.45.177:17010
Jul 15 06:31:07 kestrel pluto[14750]: | state transition function for STATE_QUICK_R0 failed: INVALID_ID_INFORMATION
Jul 15 06:31:07 kestrel pluto[14750]: | next event EVENT_NAT_T_KEEPALIVE in 18 seconds
Jul 15 06:31:18 kestrel pluto[14750]: | 
Jul 15 06:31:18 kestrel pluto[14750]: | *received 284 bytes from 208.54.45.177:17010 on eth0
Jul 15 06:31:18 kestrel pluto[14750]: | ICOOKIE:  bc e0 1c 65  d5 e7 10 64
Jul 15 06:31:18 kestrel pluto[14750]: | RCOOKIE:  a7 a9 5e bf  b1 8e 2f e3
Jul 15 06:31:18 kestrel pluto[14750]: | peer:  d0 36 2d b1
Jul 15 06:31:18 kestrel pluto[14750]: | state hash entry 31
Jul 15 06:31:18 kestrel pluto[14750]: | state object not found
Jul 15 06:31:18 kestrel pluto[14750]: | ICOOKIE:  bc e0 1c 65  d5 e7 10 64
Jul 15 06:31:18 kestrel pluto[14750]: | RCOOKIE:  a7 a9 5e bf  b1 8e 2f e3
Jul 15 06:31:18 kestrel pluto[14750]: | peer:  d0 36 2d b1
Jul 15 06:31:18 kestrel pluto[14750]: | state hash entry 31
Jul 15 06:31:18 kestrel pluto[14750]: | state object #1 found, in STATE_MAIN_R3
Jul 15 06:31:18 kestrel pluto[14750]: "l2tp-psk"[2] 208.54.45.177:17010 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x2943adee (perhaps this is a duplicated packet)
Jul 15 06:31:18 kestrel pluto[14750]: "l2tp-psk"[2] 208.54.45.177:17010 #1: sending encrypted notification INVALID_MESSAGE_ID to 208.54.45.177:17010

It is interesting that statusall shows:

00 #1: "l2tp-psk"[2] 208.54.45.177:17010 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_EXPIRE in 28656s; newest ISAKMP
000 

thanks again!
micah