Opened 3 years ago

Closed 2 years ago

#831 closed Bug / Defect (fixed-external)

Crash on second client connection

Reported by: Rottman3D Owned by: Steffan Karger
Priority: major Milestone:
Component: Crypto Version: OpenVPN 2.4.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: solaris, aes-gcm, aead, crash
Cc:

Description

After upgrading to 2.4 the server runs fine for the first client connection. Upon the second client connecting OpenVPN server crashes. Server is using the kaizawa-tuntap-v1.3.2-4 tun driver which had no problems supporting several clients under 2.3. Server does use user/password authentication. Server is running Solaris 11.3.

Attachments (1)

openvpn.log (6.2 KB) - added by Rottman3D 3 years ago.
Log file

Download all attachments as: .zip

Change History (7)

comment:1 Changed 3 years ago by Gert Döring

Can you provide a log file, please (--verb 3)? We don't regularily test the server side on (Open)Solaris, but I do not think anything in the server code is platform dependent enough to crash...

Please do also give 2.4.1 a try (to be released today).

Changed 3 years ago by Rottman3D

Attachment: openvpn.log added

Log file

comment:2 Changed 3 years ago by Rottman3D

I have updated to 2.4.2 and still have the same problem. I have attached the log (verb 3), the only thing that stands out is "Could not determine IPv4/IPv6 protocol. Using AF_INET6". This is an IPv4 Network, but this could be a red herring.

comment:3 Changed 2 years ago by Rottman3D

Recreating the certs with the newer SHA algorithms instead of MD5 solved this issue. Currently working running on 2.4.5.

comment:4 Changed 2 years ago by Gert Döring

Keywords: solaris aes-gcm aead crash added

Ah. I think I know what the problem was. AES-GCM is broken on OpenSolaris? due to "their OpenSSL library is miscompiled" - there was a thread about that on he openvpn-devel list:

https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15340.html

... SHA vs. MD5 should not have any influence on this, but maybe you also moved the client to a different --cipher, disabled NCP, or installed a fixed OpenSSL as part of an OpenSolaris? update in the meantime?

What does "pkg list entire" print? The thread says that 11.2 FCS has the issue...

The AF_INET* bit is a red herring indeed :)

comment:5 Changed 2 years ago by Rottman3D

Entire package is 0.5.11-0.175.3.28.0.4.0

I did not change the cipher but I do install new versions of openssl as new packages are released. I know in the past I had to compile openssl by hand to get some headers that Oracle decided we did not need so I can't rule out a broken openssh. Though running 2.3.x always worked while 2.4 did not.

comment:6 in reply to:  5 Changed 2 years ago by Gert Döring

Component: NetworkingCrypto
Owner: set to Steffan Karger
Resolution: fixed-external
Status: newclosed

Replying to Rottman3D:

Entire package is 0.5.11-0.175.3.28.0.4.0

That sounds like you got the update... Casper wrote that "3.22" is the "bad" version.

I did not change the cipher but I do install new versions of openssl as new packages are released. I know in the past I had to compile openssl by hand to get some headers that Oracle decided we did not need so I can't rule out a broken openssh. Though running 2.3.x always worked while 2.4 did not.

That's because 2.3 did not support AES-GCM (AEAD) modes yet... new feature in 2.4.

Our configure script detects if the functions are there, but does not actually *test* them - and then, on usage, there is a null pointer access (inside Solaris-OpenSSL) and *bam* crash.

So, by upgrading OpenSSL, you actually found and fixed the problem :-)

Just for reference should someone else bump into this and find the ticket by googling: the fix is "upgrade OpenSSL", but one possible workaround for 2.4 is to disable the auto-upgrade of ciphers to AEAD by either configuring --ncp-disable *or* set up a different --ncp-ciphers list (like, --ncp-ciphers AES-256-CBC - but to make that work, all clients need to have this configured as well).

I'm closing this ticket now, with "fixed-external", because that's what it is :)

Note: See TracTickets for help on using tickets.