[strongSwan] deleting half open IKE_SA after timeout
link at ngc.net.ua
Sat Feb 28 22:35:14 CET 2015
my previous suggestion was wrong. I've compared tcpdumps on working and non-working hosts again, and found that in broken case client continues to re-send this packed to server:
19:53:09.673551 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 1212)
126.96.36.199.4500 > 188.8.131.52.4500: [udp sum ok] NONESP-encap: isakmp 1.0 msgid 00000000 cookie 7c7f3d5d2c5f466b->5121f3fa3093c391: phase 1 I ident[E]: [encrypted id]
19:53:09.673935 IP (tos 0x0, ttl 64, id 28340, offset 0, flags [+], proto UDP (17), length 1500)
184.108.40.206.4500 > 220.127.116.11.4500: NONESP-encap: isakmp 1.0 msgid 00000000 cookie 7c7f3d5d2c5f466b->5121f3fa3093c391: phase 1 R ident[E]: [encrypted id] (len mismatch: isakmp 1660/ip 1468)
server is 18.104.22.168
I've checked network connectivity via netcat (udp, both ports - 500 and 4500) - no probelms.
Unfortunatelly didn't manage to dump traffic on client side since it's mobile devices.
Reproducable 100% times, tried 2 clients - iOS and Android. both can connect to other servers with same setings.
Asked hoster about firewall/restrictions - they said nothing blocked.
Checked freeradus - it never receives auth request from strongswan, so probably client auth message do not reach server. But since network connectivity looks fine I can't find any reason why Xauth packed should be lost. Is there anything special with Xauth that can be blocked by firewalls ?
I understand that I can't blame strongswan here, that's still looks like network issue but I need some hints to understand how to further debug it.
27.02.2015, 17:05, "Denis Zinevich" <link at ngc.net.ua>:
> Hello Martin,
> same client connects to other servers successfully, with same credentials. After I change server name - connection fails.
> and this happend only with one particular server, so according to your explanation either client didn't get XAuth request or server didn't get reply.
> I've just tried to compare tcpdumps from two machines (good and bad ones) and thet look similar except one string (with ip-proto-17)
> Thanks for your help, looks like network issue, will digg in that direction.
> 27.02.2015, 16:50, "Martin Willi" <martin at strongswan.org>:
>> Hi Denis
>>> 07[ENC] generating ID_PROT response 0 [ ID CERT SIG ]
>>> 07[NET] sending packet: from 22.214.171.124 to 126.96.36.199 (1660 bytes)
>>> 07[ENC] generating TRANSACTION request 2234314252 [ HASH CPRQ(X_USER X_PWD) ]
>>> 07[NET] sending packet: from 188.8.131.52 to 184.108.40.206 (76 bytes)
>>> 10[IKE] sending retransmit 1 of request message ID 2234314252, seq 1
>> strongSwan requests XAuth authentication from the client, but the client
>> does not seem to answer. Either it does not get the message, the user is
>> not entering the credentials in time, or more likely, it does not expect
>> an XAuth username/password request.
>> Most likely your client is not configured to do XAuth, or it is one of
>> those clients that want to skip XAuth authentication during the ISAKMP
>> reauthentication procedure (iOS, OS X). We strictly require that, as we
>> think just skipping XAuth is a security issue.
> Users mailing list
> Users at lists.strongswan.org
More information about the Users