How do I do that?
Do I have to obfuscate anything sensitive? 

---- Noel Kuntze skrev ----

>Hi Dusan,
>
>Huh, curious. Both sides use the same keys and the same algorithms with the 
>same block sizes, key sizes and truncation lengths.
>So this isn't a problem with the truncation length. Do you mind dumping the 
>ESP traffic, saving the keys of the SAs and their corresponding SPIs
>and sending those things here?
>
>Kind regards
>
>Noel
>
>On 08.08.2017 19:32, Dusan Ilic wrote:
>> Strongswan 5.2.2
>> 
>> # ip xfrm state
>> src 94.254.123.x dst 85.24.241.x
>>         proto esp spi 0xc713c2af reqid 1 mode tunnel
>>         replay-window 32 flag af-unspec
>>         auth-trunc hmac(sha256) 
>> 0x6f7a3562e5e18fafa95683bf589c6c98c2be237732a5403e22a3e48c65654314 128
>>         enc cbc(aes) 
>> 0x77bbcc462b7217af56052a6cb6c008af4052542a13d674e1d6136f6df9c8522e
>> src 85.24.241.x dst 94.254.123.x
>>         proto esp spi 0xce1e5159 reqid 1 mode tunnel
>>         replay-window 32 flag af-unspec
>>         auth-trunc hmac(sha256) 
>> 0x37110356f80804e83ceb23ecb4e7be5508445a4fdd0eb4814dbdde00dffa6033 128
>>         enc cbc(aes) 
>> 0x903c3c6c98c90f49102e839badfc7baa5ee38cf89c9ae0013c75b6556a06a345
>> 
>> # ip -s x s s
>> src 94.254.123.x dst 85.24.241.x
>>         proto esp spi 0xc713c2af(3339961007) reqid 1(0x00000001) mode tunnel
>> 
>> Strongswan 5.5.2
>> 
>> # ip xfrm state
>> src 85.24.241.x dst 94.254.123.x
>>         proto esp spi 0xce1e5159 reqid 1 mode tunnel
>>         replay-window 0 flag nopmtudisc af-unspec
>>         auth-trunc hmac(sha256) 
>> 0x37110356f80804e83ceb23ecb4e7be5508445a4fdd0eb4814dbdde00dffa6033 128
>>         enc cbc(aes) 
>> 0x903c3c6c98c90f49102e839badfc7baa5ee38cf89c9ae0013c75b6556a06a345
>> src 94.254.123.x dst 85.24.241.x
>>         proto esp spi 0xc713c2af reqid 1 mode tunnel
>>         replay-window 32 flag nopmtudisc af-unspec
>>         auth-trunc hmac(sha256) 
>> 0x6f7a3562e5e18fafa95683bf589c6c98c2be237732a5403e22a3e48c65654314 128
>>         enc cbc(aes) 
>> 0x77bbcc462b7217af56052a6cb6c008af4052542a13d674e1d6136f6df9c8522e
>> 
>> # ip -s x s s
>> src 85.24.241.x dst 94.254.123.x
>>         proto esp spi 0xce1e5159(3458093401) reqid 1(0x00000001) mode tunnel
>>         replay-window 0 seq 0x00000000 flag nopmtudisc af-unspec (0x00100100)
>>         auth-trunc hmac(sha256) 
>> 0x37110356f80804e83ceb23ecb4e7be5508445a4fdd0eb4814dbdde00dffa6033 (256 
>> bits) 128
>>         enc cbc(aes) 
>> 0x903c3c6c98c90f49102e839badfc7baa5ee38cf89c9ae0013c75b6556a06a345 (256 bits)
>>         lifetime config:
>>           limit: soft (INF)(bytes), hard 104857600(bytes)
>>           limit: soft (INF)(packets), hard (INF)(packets)
>>           expire add: soft 2522(sec), hard 3600(sec)
>>           expire use: soft 0(sec), hard 0(sec)
>>         lifetime current:
>>           6984(bytes), 94(packets)
>>           add 2017-08-08 19:23:29 use 2017-08-08 19:23:48
>>         stats:
>>           replay-window 0 replay 0 failed 0
>> src 94.254.123.x dst 85.24.241.x
>>         proto esp spi 0xc713c2af(3339961007) reqid 1(0x00000001) mode tunnel
>>         replay-window 32 seq 0x00000000 flag nopmtudisc af-unspec 
>> (0x00100100)
>>         auth-trunc hmac(sha256) 
>> 0x6f7a3562e5e18fafa95683bf589c6c98c2be237732a5403e22a3e48c65654314 (256 
>> bits) 128
>>         enc cbc(aes) 
>> 0x77bbcc462b7217af56052a6cb6c008af4052542a13d674e1d6136f6df9c8522e (256 bits)
>>         lifetime config:
>>           limit: soft (INF)(bytes), hard 104857600(bytes)
>>           limit: soft (INF)(packets), hard (INF)(packets)
>>           expire add: soft 2717(sec), hard 3600(sec)
>>           expire use: soft 0(sec), hard 0(sec)
>>         lifetime current:
>>           0(bytes), 0(packets)
>>           add 2017-08-08 19:23:29 use 2017-08-08 19:23:37
>>         stats:
>>           replay-window 0 replay 0 failed 24
>> 
>> 
>> Den 2017-08-08 kl. 18:43, skrev Noel Kuntze:
>>> Hi Dusan,
>>>
>>> I think it'd be useful, if you could post complete outputs of `ip xfrm 
>>> state` of both hosts.
>>> The last time you posted them, one of the outputs was incomplete and cut 
>>> off just above the relevant lines
>>>
>>> Kind regards
>>>
>>> Noel
>>>
>>> On 08.08.2017 18:36, Dusan Ilic wrote:
>>>>> 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 since 5.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:
>>>> 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?
>>>>>>>>>>
>>>>>>>>>>
>> 
>

Reply via email to