Hi Andreas,
Is there any support if strongswan can provide to explicitly mention
IKE integrity and PRF , in future ?
Below is what from earlier discussion, but not concluded.
http://thread.gmane.org/gmane.network.vpn.strongswan.user/2240
Will there be similar support to mention in ESP cipher
Hi Martin,
On Thursday 18 October 2012 01:12 PM, Martin Willi wrote:
Hi,
Is there any support if strongswan can provide to explicitly mention
IKE integrity and PRF, in future ?
Yes. I've implemented this last week (the last three patches from [1]),
it will be available in the next release.
On Thursday 18 October 2012 03:12 PM, Martin Willi wrote:
I have also expressed the concern to do similar provisioning for
esp= param as well. Can the check be extended for PROTO_ESP too ?
There is no PRF involved in ESP SAs, nor is a dedicated PRF used in
CHILD_SA establishment. Hence I see
Hi,
I am looking for clarification in strongswan implementation (v4.6.4 or
above) about its proposal on encryption (ENCR) algorithms while rekeying
IKE_SA using CHILD_SA. In my test, I have configured localnode running
strongswan, with ESP as:
ESP:3DES_CBC/AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
16[ENC] generating NOTIFY payload finished
I could not get what you said earlier for this value received and
rejected. As I am new in this area, can you please help me to
understand it more.
Thanks,
Gowri Shankar
Andreas
On 07/01/2012 01:39 PM, gowrishankar wrote:
Hi,
I am testing IKEv2
Hi Tobias,
On Saturday 29 September 2012 02:04 AM, Tobias Brunner wrote:
Hi Gowri,
Here, this payload is of 9 bytes as payload length also mentions
correctly. But, my doubt is on notification data which is 2D.
It is always 2D even if I set notification data on sending node (say 01).
This
On Thursday 05 July 2012 09:40 PM, Shukla, Sanjay wrote:
I have a host to host configuration
The initiator tried to create a tunnel to
the peer, however a corresponding configuration was not found.
Later on
notification instead of dropping the packet ?
Thanks,
Gowri Shankar
On Sunday 01 July 2012 10:45 AM, gowrishankar wrote:
Hi Andreas,
Thanks a lot! Yes, It was using socket-raw (as pluto is also
configured) . I disabled
explicitly in configure option and enabled socket-default, and seeing
invalid
Hi,
I am testing IKEv2 implementation for invalid but critical payload type.
strongswan seems to be sending notification payload of message type
UNSUPPORTED_CRITICAL_PAYLOAD as expected. But, notification data is
corrupted where as it should be a one-octet payload type as per
Section 2.5 of RFC
://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/network/receiver.c;h=f0cb0b2d17d153205e97f880e7daa0fdea89f974;hb=HEAD#l409
which is the basis of today's strongSwan 5.0.0 release.
Regards
Andreas
On 06/30/2012 09:13 AM, gowrishankar wrote:
strongswan: charon not reacting for higher major
, gowrishankar wrote:
Hi Andreas,
I tested in strongswan-5.0.0rc1 as well, but same problem.
I'll debug some more and post here updates.
Thanks,
Gowri Shankar
On Saturday 30 June 2012 08:38 PM, Andreas Steffen wrote:
Hi Gowri,
have a look at the following piece of code in the git repository
Hi Martin,
On Thursday 28 June 2012 01:27 PM, Martin Willi wrote:
Hi,
10[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
10[IKE] CHILD_SA rekeying failed, trying again in 24 seconds
Hence, is sending notify payload (no proposal chosen) not treated as
failure for rekey
Hi,
I am looking for a clarification wrt rekeying SA in strongswan
implementation. During a rekeying negotiation to a remote peer, if local
node receives NO_PROPOSAL_CHOSEN in notify payload as a response to
CREATE_CHILD_SA request, should n't the current IKE SA be destroyed and
created once
On Wednesday 28 March 2012 11:51 PM, eric_c_john...@dell.com wrote:
Hi.
I have a situation where ESP packets appear to be getting mangled on
the remote peer whenever I use SHA2-256-128 for Phase2 (ESP). I can
establish the SAs from the Strongswan to the remote peer no problem.
However, I
Hi Anand,
wrt RFC 4306 Page 22:
If the two ends have the same lifetime policies, it is possible that
both will initiate a rekeying at the same time (which will result in
redundant SAs). To reduce the probability of this happening, the
timing of rekeying requests SHOULD be
Hi Vilhelm,
On Wednesday 21 March 2012 03:24 PM, Vilhelm Jutvik wrote:
Hello Gowri,
this seems to be the same problem (however I cannot confirm that
SIGSEGV is the culprit in my case).
So, can you check/paste what is happening while ENC
parsing IKE_SA_INIT response for SA payload. You can
Hi Tobias,
On Wednesday 21 March 2012 12:44 AM, Vilhelm Jutvik wrote:
Dear Tobias,
thank you very much. I thought that charon was signalled by the IPsec
stack's SPD when a new SA was to be negotiated, not that it itself set
the policy.
Your solution didn't work right away though. I found
Hi,
Appreciating anyone willing to suggest possible cause(s) for the below
problem found in Test IKEv2.EN.I.1.1.1.3: Use of CHILD_SA (TAHI IKEv2
test suite). I am using strongswan version of 4.5.2, for a endnode-
endnode test, in RHEL6.2 environment.
IKE_SA_INIT is established between NUT (node
On Friday 23 December 2011 03:12 PM, Thomas Egerer wrote:
On 12/23/2011 09:40 AM, Anupam Malhotra wrote:
Hi Thomas
I did try left=xp.xp.xp.xp. In that case, even the tunnel is not
established. Is there anything else which I can try here?
Make sure that right on your cloud-server is
On Friday 23 December 2011 03:47 PM, Anupam Malhotra wrote:
Hi Thomas
The IKE_SA-negotiation is not failing. The tunnel is coming up. Only issue
is that the local IP is being seen at the remote end (rather than the public
IP).
@Gowrishankar: I added the below snippet in strongsan.conf
Hi Anupam,
On Wednesday 21 December 2011 10:53 AM, Anupam Malhotra wrote:
Hi All
We have successfully established a tunnel from a server hosted in
cloud to a remote server. On executing “ipsec status”, we can see the
“IPsec SA established” message. The cloud server has a local IP (say
21 matches
Mail list logo
