n 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 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
ioned 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 wit
st 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
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
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
> differen
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 e
; 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
tc/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 r
> 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 i
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
-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,
>
12 matches
Mail list logo
