ipsec aborts when i trying to use esp= 3des-md5-96

[IvnSoft]

Hi guys.

Im sure this is an old thing, and im sure there is a way to fix it. I did it before, but the server died and cannto remember how i did it.

I got the same config, the same version of everything i could think of (Centos 6.2, libreswan 3.15-7 from the same repo), and the relevant part of the config in ipsec.conf :

conn vpn type= tunnel authby= secret

    left=xxxx
    leftsubnet=yyyy
    leftnexthop=zzzz

    right= xxxx1
    rightsubnets= yyyy1
    rightnexthop= zzzz1

    esp= 3des-md5-96
    keyexchange= ike
    pfs= no
    auto= start

and everytime i try to connect the tunnel i get :

pluto[5137]: phase2alg string error: authentication algorithm does not take a variable key size, enc_alg="3des"(0), auth_alg="md5", modp=""

Tried with latest Centos (7.something) and i get a similar error :

ESP DH algorithm '96' is not recognized

I cant remember if i recompiled the kernel, some modules, patched something.. and ive been searching for a while now, and cant find anything relating to this. (at least, not mentioning md5 and 96.. )

So.. If anyone has the step im missing, please let me know.

[letoams]

You need to use esp=3des-md5 without any key length

Sent from mobile device

On Jul 26, 2019, at 19:16, Bruce notifications@github.com wrote:

Hi guys.

Im sure this is an old thing, and im sure there is a way to fix it. I did it before, but the server died and cannto remember how i did it.

I got the same config, the same version of everything i could think of (Centos 6.2, libreswan 3.15-7 from the same repo), and the relevant part of the config in ipsec.conf :

conn vpn type= tunnel authby= secret

left=xxxx
leftsubnet=yyyy
leftnexthop=zzzz

right= xxxx1
rightsubnets= yyyy1
rightnexthop= zzzz1

esp= 3des-md5-96
keyexchange= ike
pfs= no
auto= start

and everytime i try to connect the tunnel i get :

pluto[5137]: phase2alg string error: authentication algorithm does not take a variable key size, enc_alg="3des"(0), auth_alg="md5", modp=""

Tried with latest Centos (7.something) and i get a similar error :

ESP DH algorithm '96' is not recognized

I cant remember if i recompiled the kernel, some modules, patched something.. and ive been searching for a while now, and cant find anything relating to this. (at least, not mentioning md5 and 96.. )

So.. If anyone has the step im missing, please let me know.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[IvnSoft]

Tried that. However the tunnel wont get established as the remote peer doesnt like the proposal. (remote peer is a cisco asa, old one. I also tried reinstalling the exact same versions of the old server that ran this ipsec, and still doesnt allow me to use the key length)

[bleve]

It's likely possible that you need to set ike= option too because md5 is not in our default proposals any more - and for reason, md5 is not secure. I'd really use time to get tunnel set up with secure options instead of trying to get obviously deprecated and insecure md5 to work.

[IvnSoft]

Tried that also. No dice. If it was me, i would ditch the whole ipsec and use other security measures. However, the provider wont change its settings. (it is a goverment thing and.. they just do what they want).

Guess im going to need to fetch the server from wherever it was "stored" and check what the hell i did. (and will update here too)

Thanks anyways

[letoams]

On Jul 28, 2019, at 19:43, Bruce notifications@github.com wrote:

Tried that also. No dice. If it was me, i would ditch the whole ipsec and use other security measures.

None of the “newer” security mechanisms would support 3des nor md5. You are blaming IPsec for having offered proven security for over 20 years but expect 20 year old configurations to still work. Without an ike and esp line, IPsec provides RFC8221 and RFC 8247 recommended defaults.

However, the provider wont change its settings. (it is a goverment thing and.. they just do what they want).

md5 is not FIPS approved and 3des is DEPRECATED for FIPS 140-2 and will be DISALLOWED for FIPS 140-3, so they will have to upgrade their ends ancient configuration soon anyway.

Hopefully the above can help you to convince them to upgrade. You can also point them to:

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-77r1-draft.pdf

Paul

[IvnSoft]

I dont blame ipsec for anything. I blame the other end because they wont update their old systems. But using ipsec with their outdated (and weird firewall rules) was a hassle.

I tried to convince them. The only thing left to do, is hack/dos them and show them how vulnerable they are, but i can assure you.. it wont make a difference. (sigh)

Anyways. I found the old server, and found what i was doing wrong :

• Centos 6.2 has libreswan-3.15-7.5.el6_9.x86_64 available.
• I did downgrade that, using openswan-2.6.32-9.el6.x86_64. instead.

When using libreswan, i got this line pluto[5137]: Using Linux XFRM/NETKEY IPsec interface code on 2.6.32-220.el6.x86_64

And when using the old openswan Jul 29 11:50:01 vpnoap pluto[7366]: Using Linux 2.6 IPsec interface code on 2.6.32-220.el6.x86_64 (experimental code)

That was it. It is up and running again. So, if anyone has this issue with a provider that wont update their system, this is the answer.

Thanks for the time. ;)

[letoams]

On Mon, 29 Jul 2019, Bruce wrote:

Anyways. I found the old server, and found what i was doing wrong :

• Centos 6.2 has libreswan-3.15-7.5.el6_9.x86_64 available.
• I did downgrade that, using openswan-2.6.32-9.el6.x86_64. instead.

When using libreswan, i got this line pluto[5137]: Using Linux XFRM/NETKEY IPsec interface code on 2.6.32-220.el6.x86_64

And when using the old openswan Jul 29 11:50:01 vpnoap pluto[7366]: Using Linux 2.6 IPsec interface code on 2.6.32-220.el6.x86_64 (experimental code)

If you check the logs for the openswan version what it negotiated, you can configure that as ike/esp lines for libreswan too, and ditch the EOL centos/libreswan install.

Paul

[IvnSoft]

On Mon, 29 Jul 2019, Bruce wrote: Anyways. I found the old server, and found what i was doing wrong : Centos 6.2 has libreswan-3.15-7.5.el6_9.x86_64 available. I did downgrade that, using openswan-2.6.32-9.el6.x86_64. instead. When using libreswan, i got this line pluto[5137]: Using Linux XFRM/NETKEY IPsec interface code on 2.6.32-220.el6.x86_64 And when using the old openswan Jul 29 11:50:01 vpnoap pluto[7366]: Using Linux 2.6 IPsec interface code on 2.6.32-220.el6.x86_64 (experimental code) If you check the logs for the openswan version what it negotiated, you can configure that as ike/esp lines for libreswan too, and ditch the EOL centos/libreswan install. Paul

Not a bad idea. Will give it a try in the weekend. I will update in case i manage it to run with the latest version of libreswan.

Thanks !