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" : > 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" : > 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" : >> 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
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" : > 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
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
[strongSwan] deleting half open IKE_SA after timeout
Hello, I have several identicall servers (but in different datacenters), client can connect to any except one. configs are completely identical (ensured by cfengine, tripple re-checked manually), so probably that's not configuration issue. logs look like: Feb 27 13:58:34 s04001011709 charon: 07[ENC] generating ID_PROT response 0 [ ID CERT SIG ] Feb 27 13:58:34 s04001011709 charon: 07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (1660 bytes) Feb 27 13:58:34 s04001011709 charon: 07[ENC] generating TRANSACTION request 2234314252 [ HASH CPRQ(X_USER X_PWD) ] Feb 27 13:58:34 s04001011709 charon: 07[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (76 bytes) Feb 27 13:58:38 s04001011709 charon: 10[IKE] sending retransmit 1 of request message ID 2234314252, seq 1 Feb 27 13:58:38 s04001011709 charon: 10[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (76 bytes) Feb 27 13:58:38 s04001011709 charon: 12[NET] received packet: from 46.211.133.122[39592] to 179.179.179.179[4500] (1196 bytes) Feb 27 13:58:38 s04001011709 charon: 12[IKE] received retransmit of request with ID 0, retransmitting response Feb 27 13:58:38 s04001011709 charon: 12[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (1660 bytes) Feb 27 13:58:41 s04001011709 charon: 13[NET] received packet: from 46.211.133.122[39592] to 179.179.179.179[4500] (1196 bytes) Feb 27 13:58:41 s04001011709 charon: 13[IKE] received retransmit of request with ID 0, retransmitting response Feb 27 13:58:41 s04001011709 charon: 13[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (1660 bytes) Feb 27 13:58:44 s04001011709 charon: 15[NET] received packet: from 46.211.133.122[39592] to 179.179.179.179[4500] (1196 bytes) Feb 27 13:58:44 s04001011709 charon: 15[IKE] received retransmit of request with ID 0, retransmitting response Feb 27 13:58:44 s04001011709 charon: 15[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (1660 bytes) Feb 27 13:58:45 s04001011709 charon: 14[IKE] sending retransmit 2 of request message ID 2234314252, seq 1 Feb 27 13:58:45 s04001011709 charon: 14[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (76 bytes) Feb 27 13:58:57 s04001011709 charon: 05[NET] received packet: from 46.211.133.122[39592] to 179.179.179.179[4500] (1196 bytes) Feb 27 13:58:57 s04001011709 charon: 05[IKE] received retransmit of request with ID 0, retransmitting response Feb 27 13:58:57 s04001011709 charon: 05[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (1660 bytes) Feb 27 13:58:58 s04001011709 charon: 04[IKE] sending retransmit 3 of request message ID 2234314252, seq 1 Feb 27 13:58:58 s04001011709 charon: 04[NET] sending packet: from 179.179.179.179[4500] to 46.211.133.122[39592] (76 bytes) Feb 27 13:59:02 s04001011709 charon: 07[JOB] deleting half open IKE_SA after timeout That's it. setting log level for NET and IKE to "2" do not give more info. Have no idea how to debug/where to digg. Help me please :) -- Denis ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
