Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb

2014-01-11 Thread s s 
) 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

2014-01-10 Thread s s 
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], 
  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

Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb

2014-01-09 Thread s s 
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, 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

Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb

2014-01-07 Thread Volker Rümelin 
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

Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb

2014-01-06 Thread Volker Rümelin 
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

2014-01-06 Thread Thomas Egerer 
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*:
snip
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
snap
*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

2014-01-05 Thread Noel Kuntze 
 (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.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

Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb

2014-01-05 Thread s s 
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/N/A
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 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

Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb

2013-12-31 Thread Volker Rümelin 
 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

Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb

2013-12-30 Thread Volker Rümelin 
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

2013-12-29 Thread Noel Kuntze 

-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
 authentication of 'STR4.3host.cert' (myself) with RSA signature successful
 sending end entity cert STR4.3host.cert
 establishing CHILD_SA karmaIKE2