Hi Noel,
I think I'm already using kernel-netlink on both endpoints.
cat /etc/strongswan.d/charon/kernel-netlink.conf | grep load
# Whether to load the plugin. Can also be an integer to increase the
load = yes
Den 2017-08-04 kl. 21:00, skrev Noel Kuntze:
Hi,
If the pfkey API (nowadays a wrapper around XFRM) to the kernel is used,
SHA-256 with 96 bit truncation is used[1][2]. That is because it is the default
truncation length.
It is not possible to choose the truncation length using pfkey.
If XFRM over netlink socket is used to configure XFRM, one can choose the
truncation length. strongSwan uses the 128 bit truncation length for
HMAC-SHa256.
Since 5.5.3, one can choose the truncation length on a per-conn basis.
From the roadmap[3]:
With the sha256_96 compatibility option it's possible to locally configure
96-bit truncation
for HMAC_SHA256 (the correct truncation is 128 bit) when negotiated using the
official
algorithm identifier (12). This is only useful for compatibility with peers
that incorrectly
use this shorter truncation as the actual truncation length is not negotiated.
So the solution is to try using kernel-netlink instead of kernel-pfkey with
strongSwan in an attempt to force the kernel to
use the 128 bit truncation length, which strongSwan chooses by default.
Kind regards
Noel
[1] https://wiki.strongswan.org/issues/2301
[2] https://wiki.strongswan.org/issues/2391
[3] https://wiki.strongswan.org/versions/65
On 04.08.2017 20:50, Andreas Steffen wrote:
Hi Dusan,
the only workaround I see is to either upgrade your Linux 2.6
kernel or fall back to a SHA-1 based ESP HMAC.
Regards
Andreas
On 04.08.2017 20:46, Dusan Ilic wrote:
Hi,
Unfortunately, I'm not following you guys :)
Could someone please clarify?
Den 2017-08-04 kl. 19:04, skrev Noel Kuntze:
Hi,
IIRC pfkey still uses the old truncation (It's mentioned in some
relatively recent ticket).
Try using kernel-netlink instead.
Kind regards
Noel
On 04.08.2017 19:02, Andreas Steffen wrote:
Hi Dusan,
hmmm, our documentation says that the correct ESP SHA256_128 HMAC
truncation was introduced with the 2.6.33 kernel but your kernel
might not be a vanilla 2.6.36 kernel:
https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites
(ESP integrity algorithm footnote n)
Regards
Andreas
On 04.08.2017 16:41, Dusan Ilic wrote:
Hi Andreas
One side is 2.6.36 and the other 3.10.20
Den 2017-08-04 kl. 12:48, skrev Andreas Steffen:
Hi Dusan,
this is a Linux kernel issue. Which kernel versions are you running
on the two endpoints?.
Regards
Andreas
On 04.08.2017 12:41, Dusan Ilic wrote:
Hi Noel,
One side is Strongswan 5.2.2 and the other is 5.5.2.
How do I switch?
Den 2017-08-04 kl. 12:25, skrev Noel Kuntze:
the remote peer probably uses the DRAFT variant of sha2-256, which
uses 96 bit truncation. strongSwan uses the actual standardized
variant that truncates to 128 bit.
You can switch between the two in the newest version of strongSwan
On 04.08.2017 12:23, Dusan Ilic wrote:
Hello!
I have a strange issue, with both settings below the tunnel goes up
as it should, but only with SHA1 in ESP traffic goes through.
When I
ping the remote client with ESP SHA256 it times out, even though
the
tunnel reports as being up by Strongswan.
Traffic working:
ike=aes256-sha256-modp2048!
esp=aes128-sha1-modp2048!
Traffic not working:
ike=aes256-sha256-modp2048!
esp=aes256-sha256-modp2048!
Below combo doesn't work either:
ike=aes256-sha256-modp2048!
esp=aes128-sha256-modp2048!
Also, are above settings good? I'm having AES128 on ESP because
with
AES256 I loose too much througput. Do you have any suggestions for
change?
