Hi Thomas,

I tried your suggested proposal, but that doesnt work either.

Unfortunately, both endpoints are Linux embedded (routers), so I think that isn't an option.
However, I see that in version 5.5.3 there is a new option in Strongswan.

/sha256_96 =*no*| yes/

HMAC-SHA-256 is used with 128-bit truncation with IPsec. For compatibility with implementations that incorrectly use 96-bit truncation this option may be enabled to configure the shorter truncation length in the kernel. This is not negotiated, so this only works with peers that use the incorrect truncation length (or have this option enabled). Available since5.5.3 <https://wiki.strongswan.org/versions/65>.



Maybe I'll have to wait for the next version beeing released in the repository on the endpoint currently running 5.5.2.

Just to clarify, which of the endpoints are the failing endpoint here? I mean, which endpoint is truncating it to 96 bits?


Den 2017-08-08 kl. 09:39, skrev Thomas Egerer:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Dusan,

On 08/06/2017 08:13 PM, Dusan Ilic wrote:
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
                                             ^^- 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
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:
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?


-----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-----

Reply via email to