Hi, I have a couple of machines with Ubuntu 18.04.5 LTS (kernel 5.4.0-050400-generic x86_64) and 20.04.1 LTS (kernel 5.4.10-050410-generic x86_64). On these machines, I have installed openvpn, versions 2.4.4 (installed with apt) and 2.5.0 (compiled from sources). On every this machine I have a problem with running OpenVPN in client mode and the error I have is "Assertion failed at socket.c: 2719 (buf_defined(&sb->next))". Line number where the problem occurs differs depending on which version of OpenVPN is being tried. The 2719 is for OpenVPN 2.5.0. Following is console with the error: [img]http://dbdevco.co.uk/OpenVPN_assertion_failure.png[/img] The client configuration I am using is as follows: [img]http://dbdevco.co.uk/OpenVPN_client_config.png[/img] I am using the configuration on a number of devices on Windows or Ubuntu 16.04.7 LTS on Pi devices (ARM) without problem (have OpenVPN 2.3.10 running there with openssl in version 1.0.2g). I could not find any information on the web about this problem nor have idea what it is caused by - an issue with Ubuntu 18.04+, recent OpenVPN (version >= 2.4.4) or OpenSSL (version >=1.1.0) or the configuration I have. Please let me know if anyone experienced this issue or knows where I may find any help in solving this peculiar issue.

If you document your issue thoroughly, as described here: https://forums.openvpn.net/viewtopic.php?f=30&t=22603#p68963 Then I will raise an issue for it here: https://community.openvpn.net/openvpn/report Or you can raise the bug for yourself. FYI: OpenVPN have recently had reports that the TAP Adapter in version 2.5 is very stable. So it is interesting if you have found a new bug or replicated an old one .. Edit: Ok, this is Linux only :roll: Edited three times by me..

I suspect your use of:[code]tls-cipher "DEFAULT:@SECLEVEL=0"[/code]is the source of your problem.

Error: Assertion failed at socket.c: 2719 (buf_defined(&sb->next))

Simon30

Hi,

I have a couple of machines with Ubuntu 18.04.5 LTS (kernel 5.4.0-050400-generic x86_64) and 20.04.1 LTS (kernel 5.4.10-050410-generic x86_64).
On these machines, I have installed openvpn, versions 2.4.4 (installed with apt) and 2.5.0 (compiled from sources).

On every this machine I have a problem with running OpenVPN in client mode and the error I have is "Assertion failed at socket.c: 2719 (buf_defined(&sb->next))". Line number where the problem occurs differs depending on which version of OpenVPN is being tried. The 2719 is for OpenVPN 2.5.0.

Following is console with the error:

The client configuration I am using is as follows:

I am using the configuration on a number of devices on Windows or Ubuntu 16.04.7 LTS on Pi devices (ARM) without problem (have OpenVPN 2.3.10 running there with openssl in version 1.0.2g).

I could not find any information on the web about this problem nor have idea what it is caused by - an issue with Ubuntu 18.04+, recent OpenVPN (version >= 2.4.4) or OpenSSL (version >=1.1.0) or the configuration I have.

Please let me know if anyone experienced this issue or knows where I may find any help in solving this peculiar issue.

TinCanTech

Simon30 wrote "Assertion failed at socket.c: 2719 (buf_defined(&sb->next))"

static inline void
stream_buf_get_next(struct stream_buf *sb, struct buffer *buf)
{
    dmsg(D_STREAM_DEBUG, "STREAM: GET NEXT len=%d",
         buf_defined(&sb->next) ? sb->next.len : -1);
    ASSERT(buf_defined(&sb->next));
    *buf = sb->next;
}

I don't know what it means but it looks bad ..

Simon30

Yes, that's the part of code that executes the assertion. Someone who works on code could probably point what may be causing it. It looks like it is somehow linked to newer Ubuntu/OpenVPN/OpenSSL because the config I use works on machines with Windows (where I have OpenVPN 2.4.7 or older) or older Ubuntu/OpenVPN/OpenSSL (have a Pi on ARM with Ubuntu 16.04, as mentioned before, with OpenVPN 2.3.10).

I am familiar with software development but getting to debug OpenVPN is too heavy at the moment for me (to familiarize with the code could take weeks starting from scratch). However, if someone is working on development of OpenVPN and needs help/exposure to a VM or a computer with that Ubuntu/OpenVPN/OpenSSL configuration that results in the fatal error, can help.

TinCanTech

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

TinCanTech

I suspect your use of:

tls-cipher "DEFAULT:@SECLEVEL=0"

is the source of your problem.

Simon30

TinCanTech, thanks for replying to my post. Following your suggestion, I was preparing throughout documentation for the problem and noticed subtle issue in my configuration:

I have issued individual certificate/key pairs for each of clients but all have the same common name (CN). Looking on documentation, in such a case it is required to have "duplicate-cn" option enabled on server (when the Common Name is the same or the same key/certificate pair is reused on multiple machines). It looks like it is an issue with the certificates having the same common name and that needs to be fixed. However, adding temporarily "duplicate-cn" to server's configuration solves the problem.

It looks like there is a difference between old/Windows and new OpenVPN versions: the older versions of OpenVPN on Ubuntu/Windows OpenVPN try restart connection when duplicate-cn is not configured on server and two parallel connections appear with certificates having the same common name. The newer OpenVPN on Ubuntu, I have, fails with the mentioned assertion error and exits. It does make sense the OpenVPN on Ubuntu does not try restart connection but a more meaningful message could help a lot in the future...

TinCanTech

Simon30 wrote adding temporarily "duplicate-cn" to server's configuration solves the problem

This is definitely a bug.

Please post here your complete server and client logs at --verb 4 showing the failure. (Remove your private data)

Please post text not pictures.

https://community.openvpn.net/openvpn/ticket/1362

TinCanTech

* Bump *

Please add the log files requested.