-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Dusan,
Sorry for the delay. Busy times :) On 08/09/2017 08:24 AM, Dusan Ilic wrote: > How do I do that? tcpdump -ni <interface-name> -w /tmp/esp_dump.pcap -s 0 proto 50 The keys are obtained the same way you did in this mail, by running the 'ip -s x s s' command (which by the way is short for 'ip -s xfrm state show') interface-name: e.g. eth0 (or else) > Do I have to obfuscate anything sensitive? You should be aware of the fact, that anyone with the traffic dumps and the keys can decrypt and read the *plain* text of the traffic sent over the tunnel (and this includes IP-adresses, too). Cheers, Thomas > > ---- 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? >>>>>>>>>> >>>>>>>>>> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZjgBqAAoJEGK31ONirBTG0wAP/2daRQj1KuJjhePeBhqbekae 35tTmf1io782nV174fdR/naAevOHeWtk1PXBfo1vHUtBUs2TMnu2PwgKGh+nUZdE ZCEwvUWaH/ivP3rH2K0mlH3h8UArCk2sJIScGo7A9dhejVXKYqjE9cyjeHAFBePj ci7f7PjWP5mmvvHUMPorGA1YsEVIam9868+3Xscku6oR8ndsCvEMxavkCN9kkSH/ miRITZm5/+ft5zsZOX2serwRedP3L0R2itrzNIb/HSi0d+KopXU3WDkDuTUr62DK M9rH62AhGdxxmzZcY0NX439+ISScFfkl7qhcNxtE244rQqh9NYaKPPRV2BDoHNqS HANGfHln+gyUFhk9A8mjGibXc05Lb75WcpjO8R3lMFGRJI7VO+u9pyhElHkN5uN5 oW1dz0MbjRYmIp/m4rPv5sAQ6/VQDWdOX75T1l15xhLjADWy6K3f+XhlHlFQX2o0 OWiT33Lp6g2Qid0hkw4sYONuf3jgY1zHsOgtQ8KU+wEfZCvTYdkgZvDL3P9IUF0k /J+vqX7ArAbicKJNGHGEeUEeOkwf5wrPx8y4ad9vNc4E/P0vAxK/3VLoL7D2WiAC 7VS3XjTxu8ROxlTChX7I6S6fnLCR//aks6mROzmz9AT02ypFajyeeNyKPxUVteGh ZV7Fr9S9BLr6SBYhH+Eo =Xnt/ -----END PGP SIGNATURE-----