Re: [strongSwan] deleting half open IKE_SA after timeout
Hello Volker, I tried fragmentation=yes before, but in specific connection section, not in %default, and it didn't make any effect. Now in %default section it solved my problem. Now I have enough evidence and knowledge to troubleshoot network together with hoster tech support. Thanks a lot ! 01.03.2015, 19:17, Volker Rümelin vr_strongs...@t-online.de: Hi Denis, Hello, 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) 93.74.135.165.4500 179.179.179.179.4500: [udp sum ok] NONESP-encap: isakmp 1.0 msgid 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) 179.179.179.179.4500 93.74.135.165.4500: NONESP-encap: isakmp 1.0 msgid cookie 7c7f3d5d2c5f466b-5121f3fa3093c391: phase 1 R ident[E]: [encrypted id] (len mismatch: isakmp 1660/ip 1468) you have a network problem. As you can see from the flags [+] this is the first fragment of a UDP message. The following fragment is missing. A router or firewall dropped it on route to your server. 14:44:12.274524 IP 179.179.179.179.4500 46.211.137.122.43918: NONESP-encap: isakmp: phase 1 R ident[E] 14:44:12.274536 IP 179.179.179.179 46.211.137.122: ip-proto-17 The second packet from your working example is the fragment you are missing. If fixing your network problem is not an option, you can try if fragmentation=yes in the conn %default section in ipsec.conf helps. Regards, Volker ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] deleting half open IKE_SA after timeout
Hi Denis, Hello, 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) 93.74.135.165.4500 179.179.179.179.4500: [udp sum ok] NONESP-encap: isakmp 1.0 msgid 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) 179.179.179.179.4500 93.74.135.165.4500: NONESP-encap: isakmp 1.0 msgid cookie 7c7f3d5d2c5f466b-5121f3fa3093c391: phase 1 R ident[E]: [encrypted id] (len mismatch: isakmp 1660/ip 1468) you have a network problem. As you can see from the flags [+] this is the first fragment of a UDP message. The following fragment is missing. A router or firewall dropped it on route to your server. 14:44:12.274524 IP 179.179.179.179.4500 46.211.137.122.43918: NONESP-encap: isakmp: phase 1 R ident[E] 14:44:12.274536 IP 179.179.179.179 46.211.137.122: ip-proto-17 The second packet from your working example is the fragment you are missing. If fixing your network problem is not an option, you can try if fragmentation=yes in the conn %default section in ipsec.conf helps. Regards, Volker ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] deleting half open IKE_SA after timeout
Hello, 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) 93.74.135.165.4500 179.179.179.179.4500: [udp sum ok] NONESP-encap: isakmp 1.0 msgid 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) 179.179.179.179.4500 93.74.135.165.4500: NONESP-encap: isakmp 1.0 msgid cookie 7c7f3d5d2c5f466b-5121f3fa3093c391: phase 1 R ident[E]: [encrypted id] (len mismatch: isakmp 1660/ip 1468) server is 179.179.179.179 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 l...@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 mar...@strongswan.org: Hi Denis 07[ENC] generating ID_PROT response 0 [ ID CERT SIG ] 07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (1660 bytes) 07[ENC] generating TRANSACTION request 2234314252 [ HASH CPRQ(X_USER X_PWD) ] 07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (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. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] deleting half open IKE_SA after timeout
Hi Denis 07[ENC] generating ID_PROT response 0 [ ID CERT SIG ] 07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (1660 bytes) 07[ENC] generating TRANSACTION request 2234314252 [ HASH CPRQ(X_USER X_PWD) ] 07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (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. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] deleting half open IKE_SA after timeout
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) 14:44:09.253366 IP 46.211.137.122.44028 179.179.179.179.500: isakmp: phase 1 I ident 14:44:09.254387 IP 179.179.179.179.500 46.211.137.122.44028: isakmp: phase 1 R ident ... 14:44:12.269561 IP 46.211.137.122.43918 179.179.179.179.4500: NONESP-encap: isakmp: phase 1 I ident[E] 14:44:12.274524 IP 179.179.179.179.4500 46.211.137.122.43918: NONESP-encap: isakmp: phase 1 R ident[E] 14:44:12.274536 IP 179.179.179.179 46.211.137.122: ip-proto-17 14:44:12.274554 IP 179.179.179.179.4500 46.211.137.122.43918: NONESP-encap: isakmp: phase 2/others R #6[E] 14:44:13.177956 IP 46.211.137.122.43918 179.179.179.179.4500: NONESP-encap: isakmp: phase 1 I ident[E] 14:44:13.178322 IP 179.179.179.179.4500 46.211.137.122.43918: NONESP-encap: isakmp: phase 1 R ident[E] 14:44:13.178334 IP 179.179.179.179 46.211.137.122: ip-proto-17 14:44:16.274884 IP 179.179.179.179.4500 46.211.137.122.43918: NONESP-encap: isakmp: phase 2/others R #6[E] 14:44:16.997719 IP 46.211.137.122.43918 179.179.179.179.4500: NONESP-encap: isakmp: phase 1 I ident[E] 14:44:16.998089 IP 179.179.179.179.4500 46.211.137.122.43918: NONESP-encap: isakmp: phase 1 R ident[E] 14:44:16.998100 IP 179.179.179.179 46.211.137.122: ip-proto-17 Thanks for your help, looks like network issue, will digg in that direction. 27.02.2015, 16:50, Martin Willi mar...@strongswan.org: Hi Denis 07[ENC] generating ID_PROT response 0 [ ID CERT SIG ] 07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (1660 bytes) 07[ENC] generating TRANSACTION request 2234314252 [ HASH CPRQ(X_USER X_PWD) ] 07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (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. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
