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?
> >>>>>>
> >>>>>>
>
-- 
Noel Kuntze
IT security consultant

GPG Key ID: 0x0739AD6C
Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to