<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Thomas,<br>
<br>
I tried your suggested proposal, but that doesnt work either.<br>
<br>
Unfortunately, both endpoints are Linux embedded (routers), so I
think that isn't an option.<br>
However, I see that in version 5.5.3 there is a new option in
Strongswan.<br>
<br>
</p>
<p style="color: rgb(54, 0, 12); font-family: Verdana, sans-serif;
font-size: 10.8px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: 16.2px;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: 1;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);"><em>sha256_96 =<span
class="Apple-converted-space"> </span><strong>no</strong><span
class="Apple-converted-space"> </span>| yes</em></p>
<p style="color: rgb(54, 0, 12); font-family: Verdana, sans-serif;
font-size: 10.8px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: 16.2px;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: 1;
word-spacing: 0px; -webkit-text-stroke-width: 0px; padding-left:
2em; background-color: rgb(255, 255, 255);">HMAC-SHA-256 is used
with 128-bit truncation with IPsec. For compatibility with
implementations that incorrectly use 96-bit<br>
truncation this option may be enabled to configure the shorter
truncation length in the kernel. This is not negotiated, so this<br>
only works with peers that use the incorrect truncation length (or
have this option enabled). Available since<span
class="Apple-converted-space"> </span><a class="version"
href="https://wiki.strongswan.org/versions/65" style="color:
rgb(138, 0, 32); text-decoration: none; word-wrap: break-word;
font-weight: bold;">5.5.3</a>.</p>
<p><br>
<br>
Maybe I'll have to wait for the next version beeing released in
the repository on the endpoint currently running 5.5.2.<br>
<br>
Just to clarify, which of the endpoints are the failing endpoint
here? I mean, which endpoint is truncating it to 96 bits?<br>
</p>
<br>
<div class="moz-cite-prefix">Den 2017-08-08 kl. 09:39, skrev Thomas
Egerer:<br>
</div>
<blockquote type="cite"
cite="mid:f6baf99e-dc19-7258-3bcb-454b26523e4c@gmx.de">
<pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Dusan,
On 08/06/2017 08:13 PM, Dusan Ilic wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Thomas,
I haven't upgraded it cause that's not an option, both endpoints are routers with Linux embedded.
Below is the output after some pings from both sides.
Strongswan 5.5.2
ip -s x s s
src 85.24.241.x dst 94.254.123.x
proto esp spi 0xce291943(3458799939) reqid 1(0x00000001) mode tunnel
replay-window 0 seq 0x00000000 flag nopmtudisc af-unspec (0x00100100)
auth-trunc hmac(sha256) 0xc45dd8403c10cfd32f8fe74003cc80a309b7a0decb185826ef62ac1763ae4bcd (256 bits) 128
enc cbc(aes) 0x0abb9115383986028a844ff1e71bd0f55aa22099d76785b288803ed7204aa23e (256 bits)
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 2762(sec), hard 3600(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
1416(bytes), 25(packets)
add 2017-08-06 20:08:26 use 2017-08-06 20:08:31
stats:
replay-window 0 replay 0 failed 0
src 94.254.123.x dst 85.24.241.x
proto esp spi 0xc9359a4e(3375733326) reqid 1(0x00000001) mode tunnel
replay-window 32 seq 0x00000000 flag nopmtudisc af-unspec (0x00100100)
auth-trunc hmac(sha256) 0xfe9408ba634fe4276972fa79c9b60f12bffc766434298cb25738396d2b94dda9 (256 bits) 128
enc cbc(aes) 0x1fd6fd06781cee3bab6ed97a2f01793eded22f7360691430fdfb604c4e424066 (256 bits)
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 2895(sec), hard 3600(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
0(bytes), 0(packets)
add 2017-08-06 20:08:26 use 2017-08-06 20:08:28
stats:
replay-window 0 replay 0 failed 49
</pre>
</blockquote>
<pre wrap=""> ^^- this indicates a crypto-
graphic error with the received packets. As suspected in this thread
before, your peer -- which by the way has a very very sparse iproute2
output, did it get truncated -- most likely uses sha256 with a 96 bit
truncation.
- From quickly reading this entire thread I did not whether you have
tried the following proposal on both sides:
esp=aes128-sha256_96-modp2048!
Is building your own strongswan instance for the regular linux box an
option for you?
Cheers, Thomas
</pre>
<blockquote type="cite">
<pre wrap="">
Strongswan 5.2.2
ip -s x s s
src 94.254.123.x dst 85.24.241.x
proto esp spi 0xc9359a4e(3375733326) reqid 1(0x00000001) mode tunnel
Den 2017-08-06 kl. 16:49, skrev Thomas Egerer:
Hello Dusan,
if you haven't yet updated your kernel, we might shed some light on
the problem. Set up the tunnel with SHA256 and send a couple of
packets from both sides. Then provide the output of
'ip -s x s s'
Cheers,
Thomas
On 08/04/2017 12:23 PM, Dusan Ilic wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJZiWqTAAoJEGK31ONirBTGwM4P/09h6ueOW0FyL+ajqr2HfwA6
ubk9vbcGAZg4AlBcwgkg46lABucWWLhMN1ayaRNaLiK5pvn5pqYHOB0gk6RivDQg
gfj9koQlYrQQ2KHUt6ZOrosKSW2jzoIjz4U/aeOuI+ScHfTHuzLgSwmAi/qB17Ov
/i6Jbx25aChb+ioms4BmkQpacY37Shuq09sAh1coVZC7JMDEpsKvpsPhCV+dCWUM
FxBZOZJeWNVKPILPstF/zyc4nJFzvWssUEutJ/1tpUd8Mlehrt3xc78HbcLru5In
JWYAKLg1qjSd5nmlqJQ2at2uwOf3wfdykBZkGjVWsDGGtoLGA6+T8XMyKML0byhC
jR5+8I2NKLdtiPOoM1NbchZKjCCBR2zqNOsI833pEiqmFpjFfp4+gWqmmC0uR9cM
DAPbMCrckA6rhisqphT2i0tRAhnh4sqxCa1TjwuR+BcNWm+KKiIkhaP4NvfmHoH1
IVzZzHVCkr5/qJGOBCJM2Jc0ONI79e0xe26f4SJDn3sfEMsO5lxbM5cvN2XiZ8J7
Wu5f8aytiR4wLKHCRGvqw4hqaj0hoR505+jq4Ywos3GnEM5ylOoxLgEHT169aou+
vL1VwKYehCfQFKwI0uL70dOj3ASyjuR1dIEEBFgNL2xbGfJVEMZ1Rm7SMZb2hHph
UchHB0r5u4A2AcuTVBDR
=X/NO
-----END PGP SIGNATURE-----
</pre>
</blockquote>
<br>
</body>
</html>