Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
.168.4.10 dst 192.168.4.87 proto esp spi 0xc0ddb7a7 reqid 3 mode tunnel replay-window 32 flag 20 auth hmac(sha1) 0x99e88b87cd2c1adf1ee14a1a57ddb3ee2d0ed447 enc cbc(aes) 0xbd6f78be1edf392131bb40f217edb6ab encap type espinudp sport 4500 dport 52347 addr 0.0.0.0 Based on this experience, I shall try to implement the settings and certificates infrastructure to the production environment. Thanks once again for your persistance, help and good ideas. Regards, Serge > ----- Original Message - > From: Volker Rümelin > Sent: 01/11/14 05:26 PM > To: s s > Subject: Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb > > Hello Serge, > > > Hello Volker, > > My yesterday's conclusions regarding the networks MTU shortcomings were > > probably wrong. > > right, both your hosts work just fine. > > > I've looked into the MTU's issues and found ethernet compliant MTU 1500 > > from both sides > > 1500=1472+28 : > > [root@karma ~]# ping -c 5 -M do -s 1472 192.168.4.87 > > PING 192.168.4.87 (192.168.4.87) 1472(1500) bytes of data. > > 1480 bytes from 192.168.4.87: icmp_seq=1 ttl=128 time=3.29 ms > > 1480 bytes from 192.168.4.87: icmp_seq=2 ttl=128 time=8.03 ms > > > > Then to eliminate the the doubts I stopped down the iptbales and ran the > > same > > root@bt:~# ipsec up karmaIKE2 > > > > What I found is (merging the log the way you did): > > > > root@bt:~# ipsec up karmaIKE2 > > establishing CHILD_SA karmaIKE2 > > generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr > > N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > > > > Jan 10 23:27:53 bt charon: 10[IKE] establishing CHILD_SA karmaIKE2 > > Jan 10 23:27:53 bt charon: 10[ENC] generating IKE_AUTH request 1 [ IDi CERT > > CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > > Jan 10 23:27:53 bt charon: 10[NET] sending packet: from 10.0.2.15[4500] to > > 192.168.4.10[4500] > > > > 23:27:53.426525 IP (tos 0x0, ttl 64, id 20103, offset 0, flags [+], proto > > UDP (17), length 1500) > > 10.0.2.15.4500 > 192.168.4.10.4500: NONESP-encap: isakmp 2.0 msgid > > 0001: child_sa ikev2_auth[I]: [|v2e] (len mismatch: isakmp 1484/ip 1468) > > 23:27:53.427322 IP (tos 0x0, ttl 64, id 20103, offset 1480, flags [none], > > proto UDP (17), length 36) > > 10.0.2.15 > 192.168.4.10: udp > > > > > > The Karma side reply: > > 23:27:52.189035 IP (tos 0x0, ttl 63, id 7625, offset 0, flags [+], proto: > > UDP (17), length: 1500) 192.168.4.87.49325 > 192.168.4.10.ipsec-nat-t: > > NONESP-encap: isakmp 2.0 msgid 0001: child_sa ikev2_auth[I]: [|v2e] > > (len mismatch: isakmp 1484/ip 1468) > > 23:27:52.189057 IP (tos 0x0, ttl 63, id 7625, offset 1480, flags [none], > > proto: UDP (17), length: 36) 192.168.4.87 > 192.168.4.10: udp > > > > meaning, that karma sends back 2 packet segments due to the fragemntation > > as required > > > > But the bt receives only one of them: > > 192.168.4.10.4500 > 10.0.2.15.4500: NONESP-encap: isakmp 2.0 msgid > > 0001: child_sa ikev2_auth[R]: [|v2e] (len mismatch: isakmp 1612/ip 1468) > > > > The second completing udp packet (without the header) is missing. Hence the > > initial large packet could not be reassembled. > > > > What could drop the fragmented packets on their pathway? What could be > > considered further? > > I still think it's your NAT router. Tcpdump shows you do NAT somewhere. > > > > > Can another authentication method reduce the packet size? Could a PSK > > shared key form a smaller sized packets? > > I think so. But why don't you store the certificates on both sides and > tell strongswan not to send the certificates? > > > If a smaller packets authentication is possible, it would allow to > > troubleshoot the issue. > > > > You also mentioned that strongswan >= 5.0.2 supports fragmentation for > > IKEv1. Why IKEv1 only supports fragmentation and not IKEv2? > > Ikev1 and ikev2 are different protocols. It's only implemented for > ikev1. For ikev2 there only exists a internet draft at the moment. > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-05 > > > > > Thanks again, > > Serge > > > > Regards, > Volker ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
Hello Serge, > Hello Volker, > My yesterday's conclusions regarding the networks MTU shortcomings were > probably wrong. right, both your hosts work just fine. > I've looked into the MTU's issues and found ethernet compliant MTU 1500 from > both sides > 1500=1472+28 : > [root@karma ~]# ping -c 5 -M do -s 1472 192.168.4.87 > PING 192.168.4.87 (192.168.4.87) 1472(1500) bytes of data. > 1480 bytes from 192.168.4.87: icmp_seq=1 ttl=128 time=3.29 ms > 1480 bytes from 192.168.4.87: icmp_seq=2 ttl=128 time=8.03 ms > > Then to eliminate the the doubts I stopped down the iptbales and ran the same > root@bt:~# ipsec up karmaIKE2 > > What I found is (merging the log the way you did): > > root@bt:~# ipsec up karmaIKE2 > establishing CHILD_SA karmaIKE2 > generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr > N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > > Jan 10 23:27:53 bt charon: 10[IKE] establishing CHILD_SA karmaIKE2 > Jan 10 23:27:53 bt charon: 10[ENC] generating IKE_AUTH request 1 [ IDi CERT > CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > Jan 10 23:27:53 bt charon: 10[NET] sending packet: from 10.0.2.15[4500] to > 192.168.4.10[4500] > > 23:27:53.426525 IP (tos 0x0, ttl 64, id 20103, offset 0, flags [+], proto UDP > (17), length 1500) > 10.0.2.15.4500 > 192.168.4.10.4500: NONESP-encap: isakmp 2.0 msgid > 0001: child_sa ikev2_auth[I]: [|v2e] (len mismatch: isakmp 1484/ip 1468) > 23:27:53.427322 IP (tos 0x0, ttl 64, id 20103, offset 1480, flags [none], > proto UDP (17), length 36) > 10.0.2.15 > 192.168.4.10: udp > > > The Karma side reply: > 23:27:52.189035 IP (tos 0x0, ttl 63, id 7625, offset 0, flags [+], proto: > UDP (17), length: 1500) 192.168.4.87.49325 > 192.168.4.10.ipsec-nat-t: > NONESP-encap: isakmp 2.0 msgid 0001: child_sa ikev2_auth[I]: [|v2e] (len > mismatch: isakmp 1484/ip 1468) > 23:27:52.189057 IP (tos 0x0, ttl 63, id 7625, offset 1480, flags [none], > proto: UDP (17), length: 36) 192.168.4.87 > 192.168.4.10: udp > > meaning, that karma sends back 2 packet segments due to the fragemntation as > required > > But the bt receives only one of them: > 192.168.4.10.4500 > 10.0.2.15.4500: NONESP-encap: isakmp 2.0 msgid 0001: > child_sa ikev2_auth[R]: [|v2e] (len mismatch: isakmp 1612/ip 1468) > > The second completing udp packet (without the header) is missing. Hence the > initial large packet could not be reassembled. > > What could drop the fragmented packets on their pathway? What could be > considered further? I still think it's your NAT router. Tcpdump shows you do NAT somewhere. > > Can another authentication method reduce the packet size? Could a PSK shared > key form a smaller sized packets? I think so. But why don't you store the certificates on both sides and tell strongswan not to send the certificates? > If a smaller packets authentication is possible, it would allow to > troubleshoot the issue. > > You also mentioned that strongswan >= 5.0.2 supports fragmentation for IKEv1. > Why IKEv1 only supports fragmentation and not IKEv2? Ikev1 and ikev2 are different protocols. It's only implemented for ikev1. For ikev2 there only exists a internet draft at the moment. http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-05 > > Thanks again, > Serge > Regards, Volker ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
Hello Volker, My yesterday's conclusions regarding the networks MTU shortcomings were probably wrong. I've looked into the MTU's issues and found ethernet compliant MTU 1500 from both sides 1500=1472+28 : [root@karma ~]# ping -c 5 -M do -s 1472 192.168.4.87 PING 192.168.4.87 (192.168.4.87) 1472(1500) bytes of data. 1480 bytes from 192.168.4.87: icmp_seq=1 ttl=128 time=3.29 ms 1480 bytes from 192.168.4.87: icmp_seq=2 ttl=128 time=8.03 ms Then to eliminate the the doubts I stopped down the iptbales and ran the same root@bt:~# ipsec up karmaIKE2 What I found is (merging the log the way you did): root@bt:~# ipsec up karmaIKE2 establishing CHILD_SA karmaIKE2 generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] Jan 10 23:27:53 bt charon: 10[IKE] establishing CHILD_SA karmaIKE2 Jan 10 23:27:53 bt charon: 10[ENC] generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] Jan 10 23:27:53 bt charon: 10[NET] sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] 23:27:53.426525 IP (tos 0x0, ttl 64, id 20103, offset 0, flags [+], proto UDP (17), length 1500) 10.0.2.15.4500 > 192.168.4.10.4500: NONESP-encap: isakmp 2.0 msgid 0001: child_sa ikev2_auth[I]: [|v2e] (len mismatch: isakmp 1484/ip 1468) 23:27:53.427322 IP (tos 0x0, ttl 64, id 20103, offset 1480, flags [none], proto UDP (17), length 36) 10.0.2.15 > 192.168.4.10: udp The Karma side reply: 23:27:52.189035 IP (tos 0x0, ttl 63, id 7625, offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.4.87.49325 > 192.168.4.10.ipsec-nat-t: NONESP-encap: isakmp 2.0 msgid 0001: child_sa ikev2_auth[I]: [|v2e] (len mismatch: isakmp 1484/ip 1468) 23:27:52.189057 IP (tos 0x0, ttl 63, id 7625, offset 1480, flags [none], proto: UDP (17), length: 36) 192.168.4.87 > 192.168.4.10: udp meaning, that karma sends back 2 packet segments due to the fragemntation as required But the bt receives only one of them: 192.168.4.10.4500 > 10.0.2.15.4500: NONESP-encap: isakmp 2.0 msgid 0001: child_sa ikev2_auth[R]: [|v2e] (len mismatch: isakmp 1612/ip 1468) The second completing udp packet (without the header) is missing. Hence the initial large packet could not be reassembled. What could drop the fragmented packets on their pathway? What could be considered further? Can another authentication method reduce the packet size? Could a PSK shared key form a smaller sized packets? If a smaller packets authentication is possible, it would allow to troubleshoot the issue. You also mentioned that strongswan >= 5.0.2 supports fragmentation for IKEv1. Why IKEv1 only supports fragmentation and not IKEv2? Thanks again, Serge > - Original Message - > From: Volker Rümelin > Sent: 01/08/14 02:22 AM > To: s s > Subject: Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb > > Hello Serge, > > tcpdump shows you still have a fragmentation problem. To show the > problem I copied the interesting parts from /var/log/messages and merged > them with the output from tcpdump. > > > == the bt side === > > Jan 7 22:53:48 bt charon: 16[ENC] generating IKE_SA_INIT request 0 [ SA KE > > No N(NATD_S_IP) N(NATD_D_IP) ] > > Jan 7 22:53:48 bt charon: 16[NET] sending packet: from 10.0.2.15[500] to > > 192.168.4.10[500] > > 22:53:48.558756 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP > > (17), length 728) > > 10.0.2.15.500 > 192.168.4.10.500: isakmp 2.0 msgid : parent_sa > > ikev2_init[I]: > > 22:53:48.818954 IP (tos 0x0, ttl 64, id 24, offset 0, flags [none], proto > > UDP (17), length 493) > > 192.168.4.10.500 > 10.0.2.15.500: isakmp 2.0 msgid : parent_sa > > ikev2_init[R]: > > Jan 7 22:53:48 bt charon: 17[NET] received packet: from 192.168.4.10[500] > > to 10.0.2.15[500] > > Jan 7 22:53:48 bt charon: 17[ENC] parsed IKE_SA_INIT response 0 [ SA KE No > > N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ] > > Below you can see the IKE_AUTH request going out as two fragments which > is not a problem. > > > Jan 7 22:53:48 bt charon: 17[ENC] generating IKE_AUTH request 1 [ IDi CERT > > CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > > Jan 7 22:53:48 bt charon: 17[NET] sending packet: from 10.0.2.15[4500] to > > 192.168.4.10[4500] > > 22:53:48.923237 IP (tos 0x0, ttl 64, id 49759, offset 0, flags [+], proto > > UDP (17), length 1500) > > 10.0.2.15.4500 > 192.168.4.10.4500: NONESP-encap: isakmp 2.0 msgid > > 0001: child_sa ikev2_auth[I]: [|v2e] (len mismatch: isakmp 1484/ip 1468) > > 22:53:48.923577 IP (tos 0x0, ttl 64, id 49759, offset 1480, flags [none], &g
Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
Hello Volker, Sorry the previous message left out incomplete inadvertantly. Thank you for your precious observations. Further to them I looked into the network MTUs to find out the threshold value the fragmentation occurs at. From the GW at 192.168.4.87 : C:\>ping -f -l 1470 192.168.4.10 works fine, no packet loss ever The other side packets capture [root@karma ~]# tcpdump -i eth0 -n -v -s 0 'host 192.168.4.87' 23:12:42.118481 IP (tos 0x0, ttl 128, id 16218, offset 0, flags [DF], proto: ICMP (1), length: 1498) 192.168.4.87 > 192.168.4.10: ICMP echo request, id 1, seq 20, length 1478 23:12:42.118556 IP (tos 0x0, ttl 64, id 62712, offset 0, flags [none], proto: ICMP (1), length: 1498) 192.168.4.10 > 192.168.4.87: ICMP echo reply, id 1, seq 20, length 1478 C:\>ping -f -l 1475 192.168.4.10 Fragmentation required, but DF flag is set Ping fails. ICMP unreachable It could also be reproduced from the other karma's side: [root@karma network-scripts]# ping -M do -s 1470 192.168.4.87 PING 192.168.4.87 (192.168.4.87) 1470(1498) bytes of data. 1478 bytes from 192.168.4.87: icmp_seq=1 ttl=128 time=2.42 ms 1478 bytes from 192.168.4.87: icmp_seq=2 ttl=128 time=2.67 ms [root@karma network-scripts]# ping -M do -s 1475 192.168.4.87 From 192.168.4.10 icmp_seq=1 Frag needed and DF set (mtu = 1500) From 192.168.4.10 icmp_seq=1 Frag needed and DF set (mtu = 1500) From 192.168.4.10 icmp_seq=1 Frag needed and DF set (mtu = 1500) If I understand it correctly, the fragmented packets are just dropped on the other host side and not reassembled correctly. This could be the reason the karma.host doesn't return the fragmented IKE_AUTH request packet. Making the new search I knocked upon the message which could be a hint to resolving the issue: "Block Fragmented Packets" that is checked by default. It seems that not only does this block regular WAN traffic that is fragmented, but also blocks traffic that is part of any IPSEC VPN tunnel. Now that I know it, it seems like something I should have found, however, I would have thought that the firewall would not have blocked traffic within the tunnel. Could the Fragemnted Packets be blocked by the linux host iptables? Do you have any knowledge how to enable fragmentation packet so that they could be reassembled? There is no any particular MTU size setting on the linux host network card configuration and nothing restricts the packet size either as the network connection is over the local ethernet (for the testbed configuration and troubleshooting). Regards, Serge > - Original Message - > From: Volker Rümelin > Sent: 01/08/14 02:22 AM > To: s s > Subject: Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb > > Hello Serge, > > tcpdump shows you still have a fragmentation problem. To show the > problem I copied the interesting parts from /var/log/messages and merged > them with the output from tcpdump. > > > == the bt side === > > Jan 7 22:53:48 bt charon: 16[ENC] generating IKE_SA_INIT request 0 [ SA KE > > No N(NATD_S_IP) N(NATD_D_IP) ] > > Jan 7 22:53:48 bt charon: 16[NET] sending packet: from 10.0.2.15[500] to > > 192.168.4.10[500] > > 22:53:48.558756 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP > > (17), length 728) > > 10.0.2.15.500 > 192.168.4.10.500: isakmp 2.0 msgid : parent_sa > > ikev2_init[I]: > > 22:53:48.818954 IP (tos 0x0, ttl 64, id 24, offset 0, flags [none], proto > > UDP (17), length 493) > > 192.168.4.10.500 > 10.0.2.15.500: isakmp 2.0 msgid : parent_sa > > ikev2_init[R]: > > Jan 7 22:53:48 bt charon: 17[NET] received packet: from 192.168.4.10[500] > > to 10.0.2.15[500] > > Jan 7 22:53:48 bt charon: 17[ENC] parsed IKE_SA_INIT response 0 [ SA KE No > > N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ] > > Below you can see the IKE_AUTH request going out as two fragments which > is not a problem. > > > Jan 7 22:53:48 bt charon: 17[ENC] generating IKE_AUTH request 1 [ IDi CERT > > CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > > Jan 7 22:53:48 bt charon: 17[NET] sending packet: from 10.0.2.15[4500] to > > 192.168.4.10[4500] > > 22:53:48.923237 IP (tos 0x0, ttl 64, id 49759, offset 0, flags [+], proto > > UDP (17), length 1500) > > 10.0.2.15.4500 > 192.168.4.10.4500: NONESP-encap: isakmp 2.0 msgid > > 0001: child_sa ikev2_auth[I]: [|v2e] (len mismatch: isakmp 1484/ip 1468) > > 22:53:48.923577 IP (tos 0x0, ttl 64, id 49759, offset 1480, flags [none], > > proto UDP (17), length 36) > > 10.0.2.15 > 192.168.4.10: udp > > But from karmas reply the second fragment is missing. flags [+]: more > fragments (MF) > > > 22:53:49.033669 IP (tos 0x0, ttl 64, id 25, offset 0, f
Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
Hello Serge, tcpdump shows you still have a fragmentation problem. To show the problem I copied the interesting parts from /var/log/messages and merged them with the output from tcpdump. > == the bt side === > Jan 7 22:53:48 bt charon: 16[ENC] generating IKE_SA_INIT request 0 [ SA KE > No N(NATD_S_IP) N(NATD_D_IP) ] > Jan 7 22:53:48 bt charon: 16[NET] sending packet: from 10.0.2.15[500] to > 192.168.4.10[500] > 22:53:48.558756 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP > (17), length 728) > 10.0.2.15.500 > 192.168.4.10.500: isakmp 2.0 msgid : parent_sa > ikev2_init[I]: > 22:53:48.818954 IP (tos 0x0, ttl 64, id 24, offset 0, flags [none], proto UDP > (17), length 493) > 192.168.4.10.500 > 10.0.2.15.500: isakmp 2.0 msgid : parent_sa > ikev2_init[R]: > Jan 7 22:53:48 bt charon: 17[NET] received packet: from 192.168.4.10[500] to > 10.0.2.15[500] > Jan 7 22:53:48 bt charon: 17[ENC] parsed IKE_SA_INIT response 0 [ SA KE No > N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ] Below you can see the IKE_AUTH request going out as two fragments which is not a problem. > Jan 7 22:53:48 bt charon: 17[ENC] generating IKE_AUTH request 1 [ IDi CERT > CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > Jan 7 22:53:48 bt charon: 17[NET] sending packet: from 10.0.2.15[4500] to > 192.168.4.10[4500] > 22:53:48.923237 IP (tos 0x0, ttl 64, id 49759, offset 0, flags [+], proto UDP > (17), length 1500) > 10.0.2.15.4500 > 192.168.4.10.4500: NONESP-encap: isakmp 2.0 msgid > 0001: child_sa ikev2_auth[I]: [|v2e] (len mismatch: isakmp 1484/ip 1468) > 22:53:48.923577 IP (tos 0x0, ttl 64, id 49759, offset 1480, flags [none], > proto UDP (17), length 36) > 10.0.2.15 > 192.168.4.10: udp But from karmas reply the second fragment is missing. flags [+]: more fragments (MF) > 22:53:49.033669 IP (tos 0x0, ttl 64, id 25, offset 0, flags [+], proto UDP > (17), length 1500) > 192.168.4.10.4500 > 10.0.2.15.4500: NONESP-encap: isakmp 2.0 msgid > 0001: child_sa ikev2_auth[R]: [|v2e] (len mismatch: isakmp 1612/ip 1468) The same is true for the first and all following retransmits. > Jan 7 22:53:52 bt charon: 08[IKE] retransmit 1 of request with message ID 1 > Jan 7 22:53:52 bt charon: 08[NET] sending packet: from 10.0.2.15[4500] to > 192.168.4.10[4500] > 22:53:52.943270 IP (tos 0x0, ttl 64, id 49760, offset 0, flags [+], proto UDP > (17), length 1500) > 10.0.2.15.4500 > 192.168.4.10.4500: NONESP-encap: isakmp 2.0 msgid > 0001: child_sa ikev2_auth[I]: [|v2e] (len mismatch: isakmp 1484/ip 1468) > 22:53:52.943605 IP (tos 0x0, ttl 64, id 49760, offset 1480, flags [none], > proto UDP (17), length 36) > 10.0.2.15 > 192.168.4.10: udp > 22:53:52.949155 IP (tos 0x0, ttl 64, id 26, offset 0, flags [+], proto UDP > (17), length 1500) > 192.168.4.10.4500 > 10.0.2.15.4500: NONESP-encap: isakmp 2.0 msgid > 0001: child_sa ikev2_auth[R]: [|v2e] (len mismatch: isakmp 1612/ip 1468) > > Here is what karmas reply should look like. > the karma side === > 22:53:48.284443 IP (tos 0x0, ttl 64, id 17519, offset 0, flags [+], proto: > UDP (17), length: 1500) > 192.168.4.10.ipsec-nat-t > 192.168.4.87.61579: NONESP-encap: isakmp 2.0 > msgid 0001: child_sa ikev2_auth[]: [|v2e] (len mismatch: isakmp 1612/ip > 1468) > 22:53:48.284468 IP (tos 0x0, ttl 64, id 17519, offset 1480, flags [none], > proto: UDP (17), length: 164) > 192.168.4.10 > 192.168.4.87: udp One way to solve this, is to store the certificates locally like you already did. I can't see why this shouldn't work. Another way is to change to ikev1 and enable fragmentation support. But you need strongswan >= 5.0.2 on both sides. Please read about fragmentation support and how to enable it in http://wiki.strongswan.org/projects/strongswan/wiki/ConnSection. Both solutions don't help if you have a fragmentation problem with the Windows 8 ikev2 VPN. I don't have Windows 8 available, but I know Windows 7 sends CERTREQs for all CAs it knows. Windows sends this in several fragments because of the amount of data. I assume it is the same for Windows 8. I have a few patches for strongswan 5.1.1 which enable fragmentation support with Windows ikev1 ipsec/l2tp VPN. But this is unsupported code and only tested with Windows 7 and Windows XP. And yes you are right. Try to solve the problems one by one. Regards, Volker ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
Hello Volker, Thanks for your attention to the current pb. >sorry, but I doubt this solved your fragmentation problem. To be sure I >suggest you once again initiate a ikev2 connection and capture the >packets with tcpdump on both sides at the same time. Something like I attach the complete log from both sides below >Btw. did you read the strongswan documentation about ikev1 >fragmentation? Especially the part since which strongswan version it is >available? Ikev1 doesn't help here. Could you point me to the specific link? I've read already a lot of information material but in vain. The presumably fragmentation problem was the reason that we have started initially storing the both sides certificates locally under the strongswan 4.xx branch. This strategy worked for some time. Then all of a sudden we have been unable to initiate the WORKING connections with the roadwarrior's workstation (Win8). So we made an attempt to migrate to the strongswan 5.x branch, but stuck here with the new problem of being unable to route the connection to the remote host behind our provider's NATed gateway (it works with the public IP). The other problem we have encounted with 5.x is being unable to route transparently in between different networks like for example xx.xx.30.0/24==xx.xx.40.0/24==xx.xx.50.0/24 (it could be discussed later). Looking forward to your suggestions on resolving the issue with establishing the working IKKv2 tunnel and the routing in between the networks. Regards, Serge A complete log of the IKEv2 connection cession: == the bt side === root@bt:/etc/ipsec.d# ipsec version Linux strongSwan U4.3.2/K2.6.38 conn karmaIKE2 left=%defaultroute leftsubnet=10.0.2.0/24 leftcert=btvm34.hostCert.pem leftid=btvm@hmnet right=192.168.4.10 rightsubnet=192.168.4.0/24 rightcert=peercerts/karmaY2034.hostCert.pem rightid=@karma.hmnet keyexchange=ikev2 mobike=yes leftfirewall=yes auto=add root@bt:/etc/ipsec.d# ipsec up karmaIKE2 initiating IKE_SA karmaIKE2[1] to 192.168.4.10 generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] sending packet: from 10.0.2.15[500] to 192.168.4.10[500] received packet: from 192.168.4.10[500] to 10.0.2.15[500] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ] local host is behind NAT, sending keep alives received cert request for "OU=CA, CN=certauth" sending cert request for "OU=CA, CN=certauth" authentication of 'btvm@hmnet' (myself) with RSA signature successful sending end entity cert "OU=testbed, CN=btvm.hmnet, E=btvm@hmnet" establishing CHILD_SA karmaIKE2 generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] retransmit 1 of request with message ID 1 sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] retransmit 2 of request with message ID 1 sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] ^C root@bt:/etc/ipsec.d# ipsec down karmaIKE2 destroying IKE_SA in state CONNECTING without notification root@bt:/etc/ipsec.d# root@bt:~# ipsec statusall 000 Status of IKEv1 pluto daemon (strongSwan 4.3.2): 000 interface lo/lo ::1:500 000 interface lo/lo 127.0.0.1:500 000 interface eth0/eth0 10.0.2.15:500 000 %myid = (none) 000 loaded plugins: curl ldap random pubkey openssl hmac gmp 000 debug options: none 000 Status of IKEv2 charon daemon (strongSwan 4.3.2): uptime: 41 minutes, since Jan 07 22:53:13 2014 worker threads: 8 idle of 16, job queue load: 0, scheduled events: 2 loaded plugins: curl ldap random x509 pubkey openssl xcbc hmac agent gmp kernel-netlink stroke updown eapidentity eapmd5 eapgtc eapaka eapmschapv2 Listening IP addresses: 10.0.2.15 Connections: karmaIKE2: 10.0.2.15...192.168.4.10 karmaIKE2: local: [btvm@hmnet] uses public key authentication karmaIKE2: cert: "OU=testbed, CN=btvm.hmnet, E=btvm@hmnet" karmaIKE2: remote: [karma.hmnet] uses any authentication karmaIKE2: cert: "OU=hmnet CN=karma.hmnet" karmaIKE2: child: 10.0.2.0/24 === 192.168.4.0/24 Security Associations: karmaIKE2[2]: CONNECTING, 10.0.2.15[btvm@hmnet]...192.168.4.10[karma.hmnet] karmaIKE2[2]: IKE SPIs: 820084d6d8fb828a_i* b5a3402842ca1c16_r karmaIKE2[2]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 root@bt:~# tail -f /var/log/syslog /var/log/auth.log /var/log/messages /var/log/daemon.log |grep 'charon:' Jan 7 22:53:13 bt charon: 08[CFG] received stroke: add connection 'karmaIKE2' Jan 7 22:53:13 bt charon: 08[LIB] loaded certificate file '/etc/ipsec.d/certs/btvm34.hostCert.pem' Jan 7 22:53:13 bt charon: 08[LIB] loaded certificate file '/etc/ipsec.d/certs/peercerts/karmaY2034.hostCert.pem' Jan 7 22:53:13 bt charon: 08[CFG] added configuration 'karmaIKE2' Jan 7 22:53:13 bt charon: 08[CFG] received stroke: add connection 'karmaIKE2' Jan 7 22:53:13 bt c
Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
On 01/05/2014 10:50 PM, s s wrote: > Hello, > > I made some homework and found out different elements, which may help to > troubleshoot. > >>> This packet was a large packet and was sent as two UDP fragments. > What looked like to be a packet fragmentation, in fact appeared to be two > different CAs sent in the key exchange. > I had 2 CAs in the "cacert" folder due to the coming expiration of one of > them. So I removed the expired one and the packet duplication was solved. > > Now comes to the other issues, which I am unable to resolve. > I tried to switch to the IKE v1. > > The initial authentication is successful: > root@bt:/etc/ipsec.d# ipsec up karmaIKE2 > initiating IKE_SA karmaIKE2[4] to 192.168.4.10 > generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] > sending packet: from 10.0.2.15[500] to 192.168.4.10[500] > received packet: from 192.168.4.10[500] to 10.0.2.15[500] > parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ > N(MULT_AUTH) ] > local host is behind NAT, sending keep alives > authentication of 'b...@hmnet.ucp' (myself) with RSA signature successful > > > establishing CHILD_SA karmaIKE2 <<-- this step fails > generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr > N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > retransmit 1 of request with message ID 1 > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > > > Examining the other side logs gives: > Jan 5 18:30:45 karma charon: 04[CFG] received proposals: > ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ, > ESP:3DES_CBC/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ > Jan 5 18:30:45 karma charon: 04[CFG] configured proposals: > ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, > ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, > ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ > > Jan 5 18:30:45 karma charon: 04[IKE] no matching proposal found, sending > NO_PROPOSAL_CHOSEN Hi Serge, since you have not added an 'esp=encryption-integrity[-dhgroup][-esnmode]' line to your ipsec.conf, both daemons fall back to their default proposals (for both IKE and IPSec). For IKE they find a match, for IPSec (in this case ESP) however, they cannot find a matching proposal and the CHILD_SA setup fails. The syslog tells it quite clearly: it first lists the received proposals then the configured ones, and usually a selected one, or in your case the error. You will have to add a line to your ipsec.conf which tells charon which ESP proposal to use*: conn karmaIKE2 left=%defaultroute leftsubnet=10.0.2.0/24 leftcert=lnvo.hostCert.pem right=192.168.4.10 rightsubnet=0.0.0.0/0 rightcert=peercerts/karmaY2034.hostCert.pem keyexchange=ikev2 +esp=aes128-sha1-modp2048! mobike=yes auto=add *preferrably on both sides. If you ommit the exclamation mark, the default proposals for ESP will also be included (you may not want that). Also the 'pfs = no' has no effect with IKEv2, it's IKEv1 only. Disabling PFS for CHILD_SAS is done in IKEv2 by ommiting the dh-group from the proposal string. You can find all the info in the man page [1]. I am however still wondering why your initiating 4.3.2 box proposes algorithms that are different from the default ones. Hope this helps. Cheeers, Thomas [1] http://linux.die.net/man/5/strongswan_ipsec.conf ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
Hello Serge, > Hello, > > I made some homework and found out different elements, which may help to > troubleshoot. > >>> This packet was a large packet and was sent as two UDP fragments. > What looked like to be a packet fragmentation, in fact appeared to be two > different CAs sent in the key exchange. > I had 2 CAs in the "cacert" folder due to the coming expiration of one of > them. So I removed the expired one and the packet duplication was solved. > sorry, but I doubt this solved your fragmentation problem. To be sure I suggest you once again initiate a ikev2 connection and capture the packets with tcpdump on both sides at the same time. Something like root@bt:~ # tcpdump -i eth0 -n -v -s 0 'host 192.168.4.10' root@karma:~ # tcpdump -i eth0 -n -v -s 0 'host 192.168.4.87' And I would also like to see # tail -f /var/log/messages | grep 'charon:' from both sides. Btw. did you read the strongswan documentation about ikev1 fragmentation? Especially the part since which strongswan version it is available? Ikev1 doesn't help here. Regards, Volker ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
Here is the status of the output counters from both sides. Could anything be
concluded?
Why the IKEv2 doesn't work under the same conditions?
Serge
[root@karma strongswan]# ping 10.0.2.15
PING 10.0.2.15 (10.0.2.15) 56(84) bytes of data.
--- 10.0.2.15 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms
[root@karma strongswan]# strongswan statusall
karmaIKE2: %any...%any IKEv1
karmaIKE2: child: 192.168.4.0/24 === 10.0.2.0/24 TUNNEL
Security Associations (2 up, 0 connecting):
karmaIKE2[5]: ESTABLISHED 2 minutes ago,
192.168.4.10[karma.hmnet.ucp]...192.168.4.87[b...@hmnet.ucp]
karmaIKE2[5]: IKEv1 SPIs: 714776a1942be636_i 69cdaed984ddd6db_r*, public key
reauthentication in 2 hours
karmaIKE2[5]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
karmaIKE2{4}: INSTALLED, TUNNEL, ESP SPIs: c51580dd_i 7789acc8_o
karmaIKE2{4}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 608 bytes_o (4 pkts, 7s
ago), rekeying in 43 minutes
karmaIKE2{4}: 192.168.4.0/24 === 10.0.2.0/24
[root@karma strongswan]# ping 10.0.2.15
PING 10.0.2.15 (10.0.2.15) 56(84) bytes of data.
--- 10.0.2.15 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3000ms
karmaIKE2{4}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 1216 bytes_o (8 pkts, 2s
ago), rekeying in 41 minutes
karmaIKE2{4}: 192.168.4.0/24 === 10.0.2.0/24
root@bt:~# ping 192.168.4.10
PING 192.168.4.10 (192.168.4.10) 56(84) bytes of data.
^C
--- 192.168.4.10 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms
root@bt:~# ipsec statusall
000 "karmaIKE2":
10.0.2.0/24===10.0.2.15[b...@hmnet.ucp]---10.0.2.2...192.168.4.10[@karma.hmnet.ucp]===192.168.4.0/24;
erouted; eroute owner: #2
000 "karmaIKE2": ike_life: 10800s; ipsec_life: 3600s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 3
000 "karmaIKE2": policy: PUBKEY+ENCRYPT+TUNNEL+UP; prio: 24,24; interface:
eth0;
000 "karmaIKE2": newest ISAKMP SA: #1; newest IPsec SA: #2;
000 "karmaIKE2": IKE proposal: AES_CBC_128/HMAC_SHA1/MODP_2048
000 "karmaIKE2": ESP proposal: AES_CBC_128/HMAC_SHA1/
000
000 #2: "karmaIKE2" STATE_QUICK_I2 (sent QI2, IPsec SA established);
EVENT_SA_REPLACE in 2573s; newest IPSEC; eroute owner
000 #2: "karmaIKE2" esp.c51580dd@192.168.4.10 (420 bytes, 4s ago)
esp.7789acc8@10.0.2.15 (0 bytes); tunnel
more pings:
root@bt:~# ping 192.168.4.10
PING 192.168.4.10 (192.168.4.10) 56(84) bytes of data.
^C
--- 192.168.4.10 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3008ms
000 #2: "karmaIKE2" STATE_QUICK_I2 (sent QI2, IPsec SA established);
EVENT_SA_REPLACE in 2458s; newest IPSEC; eroute owner
000 #2: "karmaIKE2" esp.c51580dd@192.168.4.10 (756 bytes, 7s ago)
esp.7789acc8@10.0.2.15 (0 bytes); tunnel
000 #1: "karmaIKE2" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in
9416s; newest ISAKMP
> - Original Message -
> From: Noel Kuntze
> Sent: 01/05/14 10:55 PM
> To: s s, users@lists.strongswan.org
> Subject: Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello Serge,
>
> When you ping, check the traffic counters "ipsec statusall" shows you for the
> connections. If the output counter (bytes_o) is incremented each ping, your
> packets go through the tunnel. If it doesn't, it's a routing problem on your
> side.
> Taking the error message "ping" gives to you and interpreting it, might help,
> too.
>
> Regards
> Noel Kuntze
>
> On 05.01.2014 22:50, s s wrote:
> > Hello,
> >
> > I made some homework and found out different elements, which may help to
> > troubleshoot.
> >
> >>> This packet was a large packet and was sent as two UDP fragments.
> > What looked like to be a packet fragmentation, in fact appeared to be two
> > different CAs sent in the key exchange.
> > I had 2 CAs in the "cacert" folder due to the coming expiration of one of
> > them. So I removed the expired one and the packet duplication was solved.
> >
> > Now comes to the other issues, which I am unable to resolve.
> > I tried to switch to the IKE v1.
> >
> > The initial authentication is successful:
> > root@bt:/etc/ipsec.d# ipsec up karmaIKE2
> > initiating IKE_SA karmaIKE2[4] to 192.168.4.10
> > generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
> > sending packet: from 10.0.2.15[500] to 192.168.4.10[500]
> > received packet: from 192.168.4.10[500] to 10.0.2.15[500]
> > parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ
> > N(MULT_AUTH) ]
> > local host is behind NA
Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
0/24 TUNNEL
> Security Associations (2 up, 0 connecting):
>karmaIKE2[8]: ESTABLISHED 16 seconds ago,
> 192.168.4.10[karma.ucp-is.com]...192.168.4.87[b...@hmnet.ucp]
>karmaIKE2[8]: IKEv1 SPIs: 2175d162c1d066eb_i 1fb55e5a7f044c32_r*, public
> key reauthentication in 2 hours
>karmaIKE2[8]: IKE proposal:
> AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
>karmaIKE2{3}: INSTALLED, TUNNEL, ESP SPIs: cf739c9c_i ca7ad5d1_o
>karmaIKE2{3}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in
> 45 minutes
>karmaIKE2{3}: 192.168.4.0/24 === 10.0.2.0/24
>
> Anyway, the routing doesn't work in between the net-net :
>
> root@bt:/etc/ipsec.d# ping 192.168.4.10
> PING 192.168.4.10 (192.168.4.10) 56(84) bytes of data.
> ^C
> --- 192.168.4.10 ping statistics ---
> 2 packets transmitted, 0 received, 100% packet loss, time 1008ms
>
> root@bt:/etc/ipsec.d# iptables -L -n -v
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target prot opt in out source
> destination
>
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT all -- eth0 * 192.168.4.0/24
> 10.0.2.0/24 policy match dir in pol ipsec reqid 16389 proto 50
> 0 0 ACCEPT all -- * eth010.0.2.0/24
> 192.168.4.0/24 policy match dir out pol ipsec reqid 16389 proto 50
>
> root@bt:/etc/ipsec.d# ip xfrm policy
> src 10.0.2.0/24 dst 192.168.4.0/24
> dir out priority 2344
> tmpl src 10.0.2.15 dst 192.168.4.10
> proto esp reqid 16389 mode tunnel
> src 192.168.4.0/24 dst 10.0.2.0/24
> dir fwd priority 2344
> tmpl src 192.168.4.10 dst 10.0.2.15
> proto esp reqid 16389 mode tunnel
> src 192.168.4.0/24 dst 10.0.2.0/24
> dir in priority 2344
> tmpl src 192.168.4.10 dst 10.0.2.15
> proto esp reqid 16389 mode tunnel
>
>
>
> If I switch back to the IKE v2 configuration settings removing the remarks
> from
> # keyexchange=ikev2
> # mobike=yes,
> than I am stuck with the initial problem of being unable to authenticate a
> tunnel.
>
>
> Is there any way to troubleshoot this?
>
> Serge
>
>
>
>
>
>
>> - Original Message -
>> From: Volker Rümelin
>> Sent: 12/31/13 04:25 PM
>> To: s s
>> Subject: Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
>>
>>> Hello Volker,
>>>
>>>> This packet was a large packet and was sent as two UDP fragments. One or
>>>> possibly both fragments were
>>>> dropped on the route to the other side.
>>> Is it possible to handle the packets fragmentation to fix the problem?
>>> Unfortunately, the real world situation is such that in the majority of
>>> cases it is impossible to intervene on the intermediate router (provider's
>>> setup, hot spots etc).
>>> Initially this was the reason that we started to store the certificated
>>> locally on each side. Otherwise even initial IKE handshake was unsuccessful.
>>>
>>>> I can see this is still your setup with the NAT router.
>>>> you should try to fix the router.
>>> There is no possibility to do that.
>>>
>>> Looking forward to your thoughts and wish you a Happy New Year!
>>> Regards,
>>> Serge
>>>
>>>
>>
>> Hello Serge,
>>
>> for a fixed site to site tunnel I would complain to my provider, as I
>> pay for the service and they have to fix the router if it's broken.
>>
>> I agree this is not a real option for the road warrior case.
>>
>> I only have some limited experience with Windows road warriors. If
>> ikev2 VPN doesn't work, it's possible to switch back to ikev1 ipsec/l2tp
>> VPN. The proprietary ikev1 fragmentation extension
>> (http://wiki.strongswan.org/projects/strongswan/wiki/ConnSection and
>> search for fragmentation) allows to build up the tunnel and if you
>> select a small enough MTU/MRU in the ppp setup, the data packets don't
>> get fragmented. You can do the same. I have to admit this is a ugly
>> solution, but it works.
>>
>> I wish you a Happy New Year,
>> Volker
>
>
>
>
>
> Hello,
>
> I am having a persistent problem of being unable to establish a tunnel
> between two strongswan hosts
>
> root@bt:/etc/ipsec.d# ipsec up karmaIKE2
> initiating IKE_SA karmaIKE2[3] to 192.168.4.10
> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
> sending packet: from 10.0.2.15[500] to 192.16
[strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
es target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- eth0 * 192.168.4.0/24 10.0.2.0/24 policy match dir in pol ipsec reqid 16389 proto 50 0 0 ACCEPT all -- * eth0 10.0.2.0/24 192.168.4.0/24 policy match dir out pol ipsec reqid 16389 proto 50 root@bt:/etc/ipsec.d# ip xfrm policy src 10.0.2.0/24 dst 192.168.4.0/24 dir out priority 2344 tmpl src 10.0.2.15 dst 192.168.4.10 proto esp reqid 16389 mode tunnel src 192.168.4.0/24 dst 10.0.2.0/24 dir fwd priority 2344 tmpl src 192.168.4.10 dst 10.0.2.15 proto esp reqid 16389 mode tunnel src 192.168.4.0/24 dst 10.0.2.0/24 dir in priority 2344 tmpl src 192.168.4.10 dst 10.0.2.15 proto esp reqid 16389 mode tunnel If I switch back to the IKE v2 configuration settings removing the remarks from # keyexchange=ikev2 # mobike=yes, than I am stuck with the initial problem of being unable to authenticate a tunnel. Is there any way to troubleshoot this? Serge > - Original Message - > From: Volker Rümelin > Sent: 12/31/13 04:25 PM > To: s s > Subject: Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb > > > Hello Volker, > > > >> This packet was a large packet and was sent as two UDP fragments. One or > >> possibly both fragments were > >> dropped on the route to the other side. > > Is it possible to handle the packets fragmentation to fix the problem? > > Unfortunately, the real world situation is such that in the majority of > > cases it is impossible to intervene on the intermediate router (provider's > > setup, hot spots etc). > > Initially this was the reason that we started to store the certificated > > locally on each side. Otherwise even initial IKE handshake was unsuccessful. > > > >> I can see this is still your setup with the NAT router. > >> you should try to fix the router. > > There is no possibility to do that. > > > > Looking forward to your thoughts and wish you a Happy New Year! > > Regards, > > Serge > > > > > > Hello Serge, > > for a fixed site to site tunnel I would complain to my provider, as I > pay for the service and they have to fix the router if it's broken. > > I agree this is not a real option for the road warrior case. > > I only have some limited experience with Windows road warriors. If > ikev2 VPN doesn't work, it's possible to switch back to ikev1 ipsec/l2tp > VPN. The proprietary ikev1 fragmentation extension > (http://wiki.strongswan.org/projects/strongswan/wiki/ConnSection and > search for fragmentation) allows to build up the tunnel and if you > select a small enough MTU/MRU in the ppp setup, the data packets don't > get fragmented. You can do the same. I have to admit this is a ugly > solution, but it works. > > I wish you a Happy New Year, > Volker Hello, I am having a persistent problem of being unable to establish a tunnel between two strongswan hosts root@bt:/etc/ipsec.d# ipsec up karmaIKE2 initiating IKE_SA karmaIKE2[3] to 192.168.4.10 generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] sending packet: from 10.0.2.15[500] to 192.168.4.10[500] received packet: from 192.168.4.10[500] to 10.0.2.15[500] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ] local host is behind NAT, sending keep alives received cert request for "STR4.3CA" received cert request for unknown ca with keyid b0:31:27:8b:2e:4b:cd:53:6d:c4:a7:fb:e9:56:1b:9f:34:cc:71:a7 sending cert request for "STR4.3CA" authentication of 'STR4.3host.cert' (myself) with RSA signature successful sending end entity cert "STR4.3host.cert" establishing CHILD_SA karmaIKE2 generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] retransmit 1 of request with message ID 1 sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] retransmit 2 of request with message ID 1 sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] The status is stuck on "CONNECTING", which never happens: root@bt:/etc/ipsec.d# ipsec statusall karmaIKE2: 10.0.2.15...192.168.4.10 karmaIKE2: local: [STR4.3host.cert] uses public key authentication karmaIKE2: cert: "STR4.3host.cert" karmaIKE2: remote: [karma.ucp-is.com] uses any authentication karmaIKE2: cert: "KRM5.1host.cert" karmaIKE2: child: 10.0.2.0/24 === 192.168.4.0/24 Security Associations: karmaIKE2[15]: CO
Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
> Hello Volker, > >> This packet was a large packet and was sent as two UDP fragments. One or >> possibly both fragments were >> dropped on the route to the other side. > Is it possible to handle the packets fragmentation to fix the problem? > Unfortunately, the real world situation is such that in the majority of cases > it is impossible to intervene on the intermediate router (provider's setup, > hot spots etc). > Initially this was the reason that we started to store the certificated > locally on each side. Otherwise even initial IKE handshake was unsuccessful. > >> I can see this is still your setup with the NAT router. >> you should try to fix the router. > There is no possibility to do that. > > Looking forward to your thoughts and wish you a Happy New Year! > Regards, > Serge > > Hello Serge, for a fixed site to site tunnel I would complain to my provider, as I pay for the service and they have to fix the router if it's broken. I agree this is not a real option for the road warrior case. I only have some limited experience with Windows road warriors. If ikev2 VPN doesn't work, it's possible to switch back to ikev1 ipsec/l2tp VPN. The proprietary ikev1 fragmentation extension (http://wiki.strongswan.org/projects/strongswan/wiki/ConnSection and search for fragmentation) allows to build up the tunnel and if you select a small enough MTU/MRU in the ppp setup, the data packets don't get fragmented. You can do the same. I have to admit this is a ugly solution, but it works. I wish you a Happy New Year, Volker ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
Hello Volker, >This packet was a large packet and was sent as two UDP fragments. One or >possibly both fragments were >dropped on the route to the other side. Is it possible to handle the packets fragmentation to fix the problem? Unfortunately, the real world situation is such that in the majority of cases it is impossible to intervene on the intermediate router (provider's setup, hot spots etc). Initially this was the reason that we started to store the certificated locally on each side. Otherwise even initial IKE handshake was unsuccessful. > I can see this is still your setup with the NAT router. > you should try to fix the router. There is no possibility to do that. Looking forward to your thoughts and wish you a Happy New Year! Regards, Serge > - Original Message - > From: Volker Rümelin > Sent: 12/31/13 12:03 AM > To: s s, users@lists.strongswan.org > Subject: Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb > > Hello Serge, > > > Dec 29 22:23:19 karma charon: 11[ENC] generating IKE_AUTH response 1 [ IDr > > CERT AUTH SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) > > N(ADD_6_ADDR) ] > > Dec 29 22:23:19 karma charon: 11[NET] sending packet: from > > 192.168.4.10[4500] to 192.168.4.87[62698] (1612 bytes) > > This packet was a large packet and was sent as two UDP fragments. One or > possibly both fragments were > dropped on the route to the other side. > > > > > Dec 29 22:23:23 karma charon: 12[NET] received packet: from > > 192.168.4.87[62698] to 192.168.4.10[4500] (1500 bytes) > > Dec 29 22:23:23 karma charon: 12[ENC] parsed IKE_AUTH request 1 [ IDi CERT > > CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > > Dec 29 22:23:23 karma charon: 12[IKE] received retransmit of request with > > ID 1, retransmitting response > > Dec 29 22:23:23 karma charon: 12[NET] sending packet: from > > 192.168.4.10[4500] to 192.168.4.87[62698] (1612 bytes) > > Dec 29 22:23:30 karma charon: 09[NET] received packet: from > > 192.168.4.87[62698] to 192.168.4.10[4500] (1500 bytes) > > I can see this is still your setup with the NAT router. Most likely you have > a problem with this router and > you should try to fix the router. > > Regards, > Volker ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
Hello Serge, > Dec 29 22:23:19 karma charon: 11[ENC] generating IKE_AUTH response 1 [ IDr > CERT AUTH SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) > N(ADD_6_ADDR) ] > Dec 29 22:23:19 karma charon: 11[NET] sending packet: from 192.168.4.10[4500] > to 192.168.4.87[62698] (1612 bytes) This packet was a large packet and was sent as two UDP fragments. One or possibly both fragments were dropped on the route to the other side. > > Dec 29 22:23:23 karma charon: 12[NET] received packet: from > 192.168.4.87[62698] to 192.168.4.10[4500] (1500 bytes) > Dec 29 22:23:23 karma charon: 12[ENC] parsed IKE_AUTH request 1 [ IDi CERT > CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > Dec 29 22:23:23 karma charon: 12[IKE] received retransmit of request with ID > 1, retransmitting response > Dec 29 22:23:23 karma charon: 12[NET] sending packet: from 192.168.4.10[4500] > to 192.168.4.87[62698] (1612 bytes) > Dec 29 22:23:30 karma charon: 09[NET] received packet: from > 192.168.4.87[62698] to 192.168.4.10[4500] (1500 bytes) I can see this is still your setup with the NAT router. Most likely you have a problem with this router and you should try to fix the router. Regards, Volker ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
haron: 09[NET] sending packet: from 192.168.4.10[4500] to 192.168.4.87[62698] (1612 bytes) Dec 29 22:23:40 karma named[2671]: lame server resolving '62.1.119.225.dsl.dyn.forthnet.gr' (in 'dyn.forthnet.gr'?): 2001:648:2c30::191:3#53 Dec 29 22:23:43 karma charon: 13[NET] received packet: from 192.168.4.87[62698] to 192.168.4.10[4500] (1500 bytes) Dec 29 22:23:43 karma charon: 13[ENC] parsed IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] Dec 29 22:23:43 karma charon: 13[IKE] received retransmit of request with ID 1, retransmitting response Dec 29 22:23:43 karma charon: 13[NET] sending packet: from 192.168.4.10[4500] to 192.168.4.87[62698] (1612 bytes) Dec 29 22:23:52 karma charon: 07[CFG] received stroke: terminate 'karmaIKE2' Dec 29 22:23:52 karma charon: 08[IKE] deleting IKE_SA karmaIKE2[5] between 192.168.4.10[karma.mynet.com]...192.168.4.87[STR4.3host.cert] Dec 29 22:23:52 karma charon: 08[IKE] sending DELETE for IKE_SA karmaIKE2[5] Dec 29 22:23:52 karma charon: 08[ENC] generating INFORMATIONAL request 0 [ D ] Dec 29 22:23:52 karma charon: 08[NET] sending packet: from 192.168.4.10[4500] to 192.168.4.87[62698] (76 bytes) Dec 29 22:23:52 karma charon: 11[NET] received packet: from 192.168.4.87[62698] to 192.168.4.10[4500] (76 bytes) Dec 29 22:23:52 karma charon: 11[ENC] parsed INFORMATIONAL response 0 [ ] Dec 29 22:23:52 karma charon: 11[IKE] IKE_SA deleted Dec 29 22:23:52 karma vpn: - STR4.3host.cert 10.0.2.0/24 == 192.168.4.87 -- 192.168.4.10 == 192.168.4.0/24 Dec 29 22:23:52 karma charon: 10[CFG] received stroke: unroute 'karmaIKE2' [root@karma strongswan]# Do you see any particular culprits ? Thanks, Serge > ----- Original Message - > From: Noel Kuntze > Sent: 12/29/13 11:25 PM > To: s s, users@lists.strongswan.org > Subject: Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hello, > > What is the configuration of the other side and what is in the log of the > other side? > > If configured properly, strongSwan 4.x and strongSwan 5.x are compatible to > each other. > > Regards > Noel Kuntze > > On 29.12.2013 22:43, s s wrote: > > Hello, > > > > I am having a persistent problem of being unable to establish a tunnel > > between two strongswan hosts > > > > root@bt:/etc/ipsec.d# ipsec up karmaIKE2 > > initiating IKE_SA karmaIKE2[3] to 192.168.4.10 > > generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] > > sending packet: from 10.0.2.15[500] to 192.168.4.10[500] > > received packet: from 192.168.4.10[500] to 10.0.2.15[500] > > parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ > > N(MULT_AUTH) ] > > local host is behind NAT, sending keep alives > > received cert request for "STR4.3CA" > > received cert request for unknown ca with keyid > > b0:31:27:8b:2e:4b:cd:53:6d:c4:a7:fb:e9:56:1b:9f:34:cc:71:a7 > > sending cert request for "STR4.3CA" > > authentication of 'STR4.3host.cert' (myself) with RSA signature successful > > sending end entity cert "STR4.3host.cert" > > establishing CHILD_SA karmaIKE2 > > generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr > > N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > > retransmit 1 of request with message ID 1 > > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > > retransmit 2 of request with message ID 1 > > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > > > > > > The status is stuck on "CONNECTING", which never happens: > > > > root@bt:/etc/ipsec.d# ipsec statusall > > > > karmaIKE2: 10.0.2.15...192.168.4.10 > > karmaIKE2: local: [STR4.3host.cert] uses public key authentication > > karmaIKE2: cert: "STR4.3host.cert" > > karmaIKE2: remote: [karma.ucp-is.com] uses any authentication > > karmaIKE2: cert: "KRM5.1host.cert" > > karmaIKE2: child: 10.0.2.0/24 === 192.168.4.0/24 > > Security Associations: > > karmaIKE2[15]: CONNECTING, > > 10.0.2.15[STR4.3host.cert]...192.168.4.10[KRM5.1host.cert] > > karmaIKE2[15]: IKE SPIs: 6d2c0e380935a207_i* 518160338263e01f_r > > > > After 5 rekying attempts, it stops. > > > > Dec 29 22:23:27 bt charon: 07[ENC] generating IKE_AUTH request 1 [ IDi CERT > > CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > > Dec 29 22:23:27 bt charon: 07[NET] sending packet: from 10.0.2.15[4500] to > > 192.168.4.10[4500] > > > > ==> /var/lo
Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, What is the configuration of the other side and what is in the log of the other side? If configured properly, strongSwan 4.x and strongSwan 5.x are compatible to each other. Regards Noel Kuntze On 29.12.2013 22:43, s s wrote: > Hello, > > I am having a persistent problem of being unable to establish a tunnel > between two strongswan hosts > > root@bt:/etc/ipsec.d# ipsec up karmaIKE2 > initiating IKE_SA karmaIKE2[3] to 192.168.4.10 > generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] > sending packet: from 10.0.2.15[500] to 192.168.4.10[500] > received packet: from 192.168.4.10[500] to 10.0.2.15[500] > parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ > N(MULT_AUTH) ] > local host is behind NAT, sending keep alives > received cert request for "STR4.3CA" > received cert request for unknown ca with keyid > b0:31:27:8b:2e:4b:cd:53:6d:c4:a7:fb:e9:56:1b:9f:34:cc:71:a7 > sending cert request for "STR4.3CA" > authentication of 'STR4.3host.cert' (myself) with RSA signature successful > sending end entity cert "STR4.3host.cert" > establishing CHILD_SA karmaIKE2 > generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr > N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > retransmit 1 of request with message ID 1 > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > retransmit 2 of request with message ID 1 > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > > > The status is stuck on "CONNECTING", which never happens: > > root@bt:/etc/ipsec.d# ipsec statusall > >karmaIKE2: 10.0.2.15...192.168.4.10 >karmaIKE2: local: [STR4.3host.cert] uses public key authentication >karmaIKE2:cert: "STR4.3host.cert" >karmaIKE2: remote: [karma.ucp-is.com] uses any authentication >karmaIKE2:cert: "KRM5.1host.cert" >karmaIKE2: child: 10.0.2.0/24 === 192.168.4.0/24 > Security Associations: >karmaIKE2[15]: CONNECTING, > 10.0.2.15[STR4.3host.cert]...192.168.4.10[KRM5.1host.cert] >karmaIKE2[15]: IKE SPIs: 6d2c0e380935a207_i* 518160338263e01f_r > > After 5 rekying attempts, it stops. > > Dec 29 22:23:27 bt charon: 07[ENC] generating IKE_AUTH request 1 [ IDi CERT > CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > Dec 29 22:23:27 bt charon: 07[NET] sending packet: from 10.0.2.15[4500] to > 192.168.4.10[4500] > > ==> /var/log/syslog <== > Dec 29 22:23:31 bt charon: 09[IKE] retransmit 1 of request with message ID 1 > Dec 29 22:23:31 bt charon: 09[NET] sending packet: from 10.0.2.15[4500] to > 192.168.4.10[4500] > > ==> /var/log/daemon.log <== > Dec 29 22:23:31 bt charon: 09[IKE] retransmit 1 of request with message ID 1 > Dec 29 22:23:31 bt charon: 09[NET] sending packet: from 10.0.2.15[4500] to > 192.168.4.10[4500] > > ==> /var/log/syslog <== > Dec 29 22:23:38 bt charon: 15[IKE] retransmit 2 of request with message ID 1 > Dec 29 22:23:38 bt charon: 15[NET] sending packet: from 10.0.2.15[4500] to > 192.168.4.10[4500] > > > > The policy for the channel does sets up, but nothing works > > [root@karma strongswan]# ip xfrm policy > src 10.0.2.0/24 dst 192.168.4.0/24 > dir in priority 1859 > tmpl src 192.168.4.87 dst 192.168.4.10 > proto esp reqid 4 mode tunnel > src 192.168.4.0/24 dst 10.0.2.0/24 > dir out priority 1859 > tmpl src 192.168.4.10 dst 192.168.4.87 > proto esp reqid 4 mode tunnel > src 10.0.2.0/24 dst 192.168.4.0/24 > dir fwd priority 1859 > tmpl src 192.168.4.87 dst 192.168.4.10 > proto esp reqid 4 mode tunnel > > > Any hint how to fix it would be highly appreciated, > Regards, > Serge > > > > > > > Is the 4.xx branch compatible with the 5.x one? > I am unable to establish a tunnel in between 2 strongswan hosts one running > the strongSwan U4.3.2/K2.6.38 > and the second strongSwan U5.1.1/K2.6.18-308.16.1.el5PAE > > The configuration is more than classical: net-net > > > conn karmaIKE2 > left=%defaultroute > leftsubnet=10.0.2.0/24 > leftcert=lnvo.hostCert.pem > right=192.168.4.10 > rightsubnet=192.168.4.0/24 > rightcert=peercerts/karmaY2034.hostCert.pem > keyexchange=ikev2 > mobike=yes > auto=add > > > root@bt:/etc/ipsec.d# ipsec up karmaIKE2 > initiating IKE_SA karmaIKE2[1] to 192.168.4.10 > generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] > sending packet: from 10.0.2.15[500] to 192.168.4.10[500] > received packet: from 192.168.4.10[500] to 10.0.2.15[500] > parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ > N(MULT_AUTH) ] > local host is behind NAT, sending keep alives > received cert request for "STR4.3CA" > received cert request for unknown ca with keyid > b0:31:27:8b:2e:4b:cd:53:6d:c4:a7:fb:e9:56:1b:9f:34:cc:71:a7 > sending cert request for "STR4.3CA" > authentica
[strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
Hello, I am having a persistent problem of being unable to establish a tunnel between two strongswan hosts root@bt:/etc/ipsec.d# ipsec up karmaIKE2 initiating IKE_SA karmaIKE2[3] to 192.168.4.10 generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] sending packet: from 10.0.2.15[500] to 192.168.4.10[500] received packet: from 192.168.4.10[500] to 10.0.2.15[500] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ] local host is behind NAT, sending keep alives received cert request for "STR4.3CA" received cert request for unknown ca with keyid b0:31:27:8b:2e:4b:cd:53:6d:c4:a7:fb:e9:56:1b:9f:34:cc:71:a7 sending cert request for "STR4.3CA" authentication of 'STR4.3host.cert' (myself) with RSA signature successful sending end entity cert "STR4.3host.cert" establishing CHILD_SA karmaIKE2 generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] retransmit 1 of request with message ID 1 sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] retransmit 2 of request with message ID 1 sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] The status is stuck on "CONNECTING", which never happens: root@bt:/etc/ipsec.d# ipsec statusall karmaIKE2: 10.0.2.15...192.168.4.10 karmaIKE2: local: [STR4.3host.cert] uses public key authentication karmaIKE2: cert: "STR4.3host.cert" karmaIKE2: remote: [karma.ucp-is.com] uses any authentication karmaIKE2: cert: "KRM5.1host.cert" karmaIKE2: child: 10.0.2.0/24 === 192.168.4.0/24 Security Associations: karmaIKE2[15]: CONNECTING, 10.0.2.15[STR4.3host.cert]...192.168.4.10[KRM5.1host.cert] karmaIKE2[15]: IKE SPIs: 6d2c0e380935a207_i* 518160338263e01f_r After 5 rekying attempts, it stops. Dec 29 22:23:27 bt charon: 07[ENC] generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] Dec 29 22:23:27 bt charon: 07[NET] sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] ==> /var/log/syslog <== Dec 29 22:23:31 bt charon: 09[IKE] retransmit 1 of request with message ID 1 Dec 29 22:23:31 bt charon: 09[NET] sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] ==> /var/log/daemon.log <== Dec 29 22:23:31 bt charon: 09[IKE] retransmit 1 of request with message ID 1 Dec 29 22:23:31 bt charon: 09[NET] sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] ==> /var/log/syslog <== Dec 29 22:23:38 bt charon: 15[IKE] retransmit 2 of request with message ID 1 Dec 29 22:23:38 bt charon: 15[NET] sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] The policy for the channel does sets up, but nothing works [root@karma strongswan]# ip xfrm policy src 10.0.2.0/24 dst 192.168.4.0/24 dir in priority 1859 tmpl src 192.168.4.87 dst 192.168.4.10 proto esp reqid 4 mode tunnel src 192.168.4.0/24 dst 10.0.2.0/24 dir out priority 1859 tmpl src 192.168.4.10 dst 192.168.4.87 proto esp reqid 4 mode tunnel src 10.0.2.0/24 dst 192.168.4.0/24 dir fwd priority 1859 tmpl src 192.168.4.87 dst 192.168.4.10 proto esp reqid 4 mode tunnel Any hint how to fix it would be highly appreciated, Regards, Serge Is the 4.xx branch compatible with the 5.x one? I am unable to establish a tunnel in between 2 strongswan hosts one running the strongSwan U4.3.2/K2.6.38 and the second strongSwan U5.1.1/K2.6.18-308.16.1.el5PAE The configuration is more than classical: net-net conn karmaIKE2 left=%defaultroute leftsubnet=10.0.2.0/24 leftcert=lnvo.hostCert.pem right=192.168.4.10 rightsubnet=192.168.4.0/24 rightcert=peercerts/karmaY2034.hostCert.pem keyexchange=ikev2 mobike=yes auto=add root@bt:/etc/ipsec.d# ipsec up karmaIKE2 initiating IKE_SA karmaIKE2[1] to 192.168.4.10 generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] sending packet: from 10.0.2.15[500] to 192.168.4.10[500] received packet: from 192.168.4.10[500] to 10.0.2.15[500] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ] local host is behind NAT, sending keep alives received cert request for "STR4.3CA" received cert request for unknown ca with keyid b0:31:27:8b:2e:4b:cd:53:6d:c4:a7:fb:e9:56:1b:9f:34:cc:71:a7 sending cert request for "STR4.3CA" authentication of 'STR4.3host.cert' (myself) with RSA signature successful sending end entity cert "STR4.3host.cert" establishing CHILD_SA karmaIKE2 generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] retransmit 1 of request with message ID 1 sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] But the tunnel root@bt:/etc/ipsec.d# ipsec statusall 000 Status of IKEv1 pluto daemon (stro
