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

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

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

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

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

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

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

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.

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

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

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

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

2014-01-05 Thread 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

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

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

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,