Hi Zhiheng,
> I am also seeing this UDP_ENCAP error in 5.0.1rc1 on my Red Hat Enterprise
> Linux 5.6 machine.
> I did not see it in the 5.0.0 release, so looks like this error is new
in 5.0.1 and is happening not only on the FreeBSD:
> Sep 27 11:44:53 sit-iwf charon: 00[DMN] Starting IKE charon
On 27 September 2012 11:13, Robert Woodcock
wrote:
> I can replicate this as well - usually in 2-5 hours with 3.2.23 and 3.4.11,
> on 82571EB NICs and a E3-1270 CPU. I don't have a full call trace yet (need
> to set up a serial console first) but the last 25 lines of mine look pretty
> similar to
Hi Tobias,
I am also seeing this UDP_ENCAP error in 5.0.1rc1 on my Red Hat Enterprise
Linux 5.6 machine. I did not see it in the 5.0.0 release, so looks like this
error is new in 5.0.1 and is happening not only on the FreeBSD:
Sep 27 11:44:53 sit-iwf charon: 00[DMN] Starting IKE charon daemon (
I can replicate this as well - usually in 2-5 hours with 3.2.23 and 3.4.11,
on 82571EB NICs and a E3-1270 CPU. I don't have a full call trace yet (need
to set up a serial console first) but the last 25 lines of mine look pretty
similar to yours.
I'm using tunnel mode, not transport, with aes128gc
This probably is not a strongswan issue, as it is the Linux kernel
that crashes. But, I felt the wider community may have seen this and
have some opinions on how to avoid it.
My ipsec.conf summary is as follows:
esp=aes128gcm12-modp1024
ike=aes-sha1-modp1024
type=transport
When I use the hardwar
On 27 September 2012 04:04, Tobias Brunner wrote:
> Hi Guru,
>
>> My primary goal is to disable the replay protection. In
>> strongswan.conf, if I set the "replay_window = 0" (or any value <=
>> 32), I see the replay window to be stuck at 32 (when seen with setkey
>> -D).
>
> You couldn't configur
We have an issue configuring Strongswan to a Cisco router.
The connection is made, but I'm not getting the routing correct. There
are multiple networks behind the router on the remote side (operated by
a vendor) and we need to snat the IP's we come from to match their
assigned range (so it rou
Hi,
Please try to keep the discussion on the list.
> Could you please once again confirm the problem scenario I have
> pointed in the first mail?
>
> Is it because of Certificate corruption or Is it failed, because there
> is no support in Strongswan?
If you are talking about the error:
> 08[L
I just went through this same problem -- still struggling with routing but seem
to habe the connection.
What's the Cisco config and you ipsec.conf?
Neeraj Sharma wrote:
>I tried doing this a couple of times and did succeed with configuring a
>StrongSwan client connecting to a Cisco ASA 5510 in
I tried doing this a couple of times and did succeed with configuring a
StrongSwan client connecting to a Cisco ASA 5510 in IKEv1/PSK Main Mode. What
works at present is the IKEv1/PSK Aggressive mode. I am no Cisco expert, so its
possible (pointed by endre that it works as well over freenode #st
Hi,
> Whether Certificate signing using SHA256 is supported in Strongswan.
strongSwan can use and verify certificates signed with SHA256, and it
can issue certificates using SHA256 with our pki tool.
> src/libcharon/sa/ikev2/authenticators/pubkey_authenticator.c
>
> switch (private->get_typ
Hi Guru,
> My primary goal is to disable the replay protection. In
> strongswan.conf, if I set the "replay_window = 0" (or any value <=
> 32), I see the replay window to be stuck at 32 (when seen with setkey
> -D).
You couldn't configure the replay window to be below the default of 32
via strongs
Hi David,
> The first was some simple compile errors which I think I fixed in the
> attached patch.
Thanks, applied to master.
> On startup I get the following messages:
>
> 00[DMN] Starting IKE charon daemon (strongSwan 5.0.1rc1, FreeBSD
> 9.0-RELEASE-p4, amd64)
> 00[KNL] unable to set UDP_EN
Hi Tobias,
yes I would strongly advocate a specific proposal for
Android clients using libipsec, restricted to AES combined
with SHA1/SHA2.
And we should definitively add HMAC_SHA2_256_128 to
our default ESP proposal, putting it in front of
AES_XCBC_96 and HMAC_MD5_96.
Andreas
On 27.09.2012 09:
Hi Andreas,
> in fact, very strange collection of cipher suites the
> strongSwan Android client is proposing:
>
> received proposals: 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
>
> I'm not aware that libip
Hmmm,
in fact, very strange collection of cipher suites the
strongSwan Android client is proposing:
received proposals: 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
I'm not aware that libipsec would support blowfish
16 matches
Mail list logo
