Hii!!
I’m having a problem with IPSEC traffic in version 7 when we use 3DES as the encryption algorithm in phase 2.
Info:
The IPSEC Proposal is (OK in v6, KO in v7):
- Auth Alg: SHA1
- Enc Alg: 3DES
- Lifetime: 00:30:00
- PFS Group: none
The IPSEC Proposal is (OK in v6, OK in v7):
- Auth Alg: SHA1
- Enc Alg: AES-256-CBC
- Lifetime: 00:30:00
- PFS Group: none
- Hardware: CCR1009-7G-1C-1S+
–
- Version v6.49.18 → With this version the IPSEC is working fine
- Version v7.18.2 →
The IPSEC tunnel is established without any problems.
We can see how the TX and RX packets and bytes on the IPSEC connection increase (packets in the NAT table increase too)… but the response is NOT received. With version 6, it does work!!
With version 7, if we change 3DES in Phase 2 - Proposal to AES 256 (for example) on both endpoints, the problem doesn’t occur.
The problem is that we have to use 3DES…
Any solution to this problem?
BR
Sergio
3DES is considered insecure and it’s deprecated:
A CVE released in 2016, CVE-2016-2183, disclosed a major security vulnerability in the DES and 3DES encryption algorithms. This CVE, combined with the inadequate key size of 3DES, led to NIST deprecating 3DES in 2019 and disallowing all uses (except processing already encrypted data) by the end of 2023.
Source: https://en.m.wikipedia.org/wiki/Triple_DES
That’s why better use AES, as you apparently have the chance to
Thank you very much for your response.
We can’t choose this configuration; it depends on the client. We know the importance of using AES, but it’s not up to us.
In any case, everything works fine with v6 (with 3DES), and the IPsec tunnel is established correctly with 3DES with v7, however the response packets aren’t received (although the number of TX/RX packets increases).
BR
Sergio
Did you managed to solve this issue? I’m facing the same with a customer that uses very old CISCO equipment.
Regards,
Stoyan Mishev