Dear All, Need some help here, I am using ASUS RT-AC56S. Within the router, it comes with OpenVPN. Over the years with OpenVPN App (1.1.21), I have no problem connecting it. With the recent update it connect fails and cause my OpenVPN Server on my router to shut down. People who download the update also complain that they have connection issues. https://play.google.com/store/apps/details?id=net.openvpn.openvpn&hl=en [b][u]My Error message as follow from the Router:[/u][/b] TLS: Initial packet from [AF_INET]xxx.xxx.xxx.xxx:24266 (via [AF_INET]xxx.xxx.xxx.xxx%eth0), sid=aaada127 1a874fe6 Assertion failed at ssl.c:2005 Exiting due to fatal error /sbin/route del -net 10.8.0.0 netmask 255.255.255.0 Closing TUN/TAP interface /sbin/ifconfig tun21 0.0.0.0 [b][u]Other information as follow:[/u][/b] rc_service: httpds 421:notify_rc stop_openvpnd;restart_samba Samba Server: smb daemon is stoped kernel: gro disabled kernel: gro enabled with interval 2 Samba Server: daemon is started rc_service: httpds 421:notify_rc restart_openvpnd;restart_chpass;restart_samba openvpn[24984]: OpenVPN 2.3.2 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [eurephia] [MH] [IPv6] built on Jun 2 2017 openvpn[24984]: PLUGIN_INIT: POST /usr/lib/openvpn-plugin-auth-pam.so '[/usr/lib/openvpn-plugin-auth-pam.so] [openvpn]' intercepted=PLUGIN_AUTH_USER_PASS_VERIFY openvpn[24984]: Diffie-Hellman initialized with 2048 bit key openvpn[24984]: WARNING: POTENTIALLY DANGEROUS OPTION --client-cert-not-required may accept clients which do not present a certificate openvpn[24984]: Socket Buffers: R=[122880->131072] S=[122880->131072] openvpn[24984]: TUN/TAP device tun21 opened openvpn[24984]: TUN/TAP TX queue length set to 100 openvpn[24984]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 openvpn[24984]: /sbin/ifconfig tun21 10.8.0.1 pointopoint 10.8.0.2 mtu 1500 openvpn[24984]: /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2 openvpn[24990]: UDPv4 link local (bound): [undef] openvpn[24990]: UDPv4 link remote: [undef] openvpn[24990]: MULTI: multi_init called, r=256 v=256 openvpn[24990]: IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0 openvpn[24990]: Initialization Sequence Completed Samba Server: smb daemon is stoped kernel: gro disabled kernel: gro enabled with interval 2 Samba Server: daemon is started Can anyone help ??

[quote]https://play.google.com/store/apps/details?id=net.openvpn.openvpn&hl=en What's New Changes from 1.1.21 to 1.1.22: * fix for importing profiles using external certificates/bundles[/quote]Thanks to your own link above .. [quote=l0ck0n post_id=73985 time=1509526156 user_id=42255] With the recent update it connect fails and cause my OpenVPN Server on my router to shut down [/quote]Exactly what version of openvpn is that ? Please post your complete server log at verb 4.

After updating to OpenVPN Connect 1.1.22 (build 89), on my mobile phone, I can't connect to my home router. (ASUS RT-N66U running OpenVPN 2.4.3 mipsel-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct 3 2017) Connecting from my Windows laptop keeps working fine! Yesterday, before the 1.1.22 Android update on my phone, all was working fine. In other words, it seems there is something wrong with the recent 'OpenVPN Connect' update for Android. Error message I get on my phone: "OpenVPN server certificate verification failed : mbed TLS: SSL read error : X509 - Certificate verification failed, e.g. CRL, CA or signature check failed". On the server site (my router) I see NO error messages, just a client restart message. - Connection reset, restarting [0] - SIGUSR1[soft,connection-reset] received, client-instance restarting Bug or am I missing something?

Same problem here. My server is openvpn 2.3.8 on an OpenSuSE system. The server logs say only this: 2017-11-01T10:25:40.039357-07:00 mallet openvpn[8229]: TCP connection established with [AF_INET]134.173.211.213:45993 2017-11-01T10:25:40.069357-07:00 mallet openvpn[8229]: 134.173.211.213:45993 Connection reset, restarting [-1] I'm going to try to see if I can downgrade on Google Play until somebody figures this out.

New user here. Zero issues connecting last night. I see my Android app updated last night on my phone, and can't connect. The logs show everything is pointed to the right destination, but I get this in the logs: "server poll timeout trying next remote entry" On the front end it says connection timeout. Tried a bunch of different settings in the OpenVPN Connect client for Android one at a time and then reverting back to how everything was configured when it was working last night, no changes made any difference. Tried restarting my OpenVPN server on my Netgear router, no change. Logs on my router show no activity on VPN since last night.

My connection gone i cannot connect with android. I checked server logs it says TLS handshake failed plaintext buffer too short. I tried to find a fix because it connects on windows. So i downloaded another openvpn client from playstore and it works. I guess new update broke TLS.

Same issue here. app updated 1-2 days ago and now it can't connect. Tried reboot hard and soft, /etc/init.d/openvpn restart, ensured the ports are forwarded, apt-get update on system, apt-get upgrade on system, verified no changes on client or server side files, and same firewall rules, nothing blocking it. Set the app to try infinitely and after about 3-5 minutes it just says "Session invalidated: KEEPALIVE_TIMEOUT". As TinCanTech noted above though, there are tons of reviews on the app from 10/31 and 11/01 saying they can't connect anymore so hopefully they take note and resolve the issue.

Further evidence: I managed to restore 1.1.17 (app only, not data) from a backup and it works again.

[quote=SharpThunder post_id=74042 time=1509570516 user_id=42276] My connection gone i cannot connect with android. I checked server logs it says TLS handshake failed plaintext buffer too short. I tried to find a fix because it connects on windows. So i downloaded another openvpn client from playstore and it works. I guess new update broke TLS. [/quote] My exact error as well. Guess we need to wait for a fix. I'm going to try reverting to an earlier version in the meantime.

[quote=SharpThunder post_id=74042 time=1509570516 user_id=42276] My connection gone i cannot connect with android. I checked server logs it says TLS handshake failed plaintext buffer too short. I tried to find a fix because it connects on windows. So i downloaded another openvpn client from playstore and it works. I guess new update broke TLS. [/quote] My exact error as well. Guess we need to wait for a fix. I'm going to try reverting to an earlier version in the meantime. EDIT: Reverting back to 1.1.17 works https://www.apkmirror.com/apk/openvpn/openvpn-connect/openvpn-connect-1-1-17-release/openvpn-connect-1-1-17-android-apk-download/

found the solution. Have to install the update from the source for the server to version 2.4. They haven't put 2.4 into apt-get yet. Someone else posted on the forum already, but in case you guys can't find it, just download the 2.4 tarball from here: https://openvpn.net/index.php/open-source/downloads.html extract it, then follow the instructions here: https://www.htpcguides.com/compile-latest-openvpn-from-source-on-debian-8/ also, don't forget to do the "sudo /etc/init.d/openvpn restart" or a reboot. Should be good to go after that.

OpenVPN update from 1.1.21 to 1.1.22 (Google Play)

gkuenning

1.1.23 fails for me as well.

gkuenning

ordex wrote Hi,
OpenVPN Connect for Android already supports "legacy" mode, but it goes as back as RSA with 1024 bits keys.

Providing a workaround to still accept MD5 basically means opening a (big) security hole and that is not really acceptable.

I know it can be troublesome, but servers still using MD5 should *really* upgrade to something stronger.
MD5 has been broken for years now and supporting it means being unprofessional towards our users.

However, this is different from the bug discussed by the OP of this post. I am glad to hear that the original problem was solved by 1.1.23.

Cheers,

Unfortunately it fails even if you don't use MD5. My certificate is 1024-bit RSA, SHA1 with RSA encryption as the signature algorithm. And 1.1.23 doesn't work. 1.1.17 does.

openwhat

Same here, I don't use MD5.

A few Server settings I use:

- Authorization Mode: TLS
- Extra HMAC authorization (tls-auth / tls-crypt): Incoming Auth (0)
- Legacy/fallback cipher: AES-128-CBC
- Auth digest: SHA1
- Compression: LZO

TinCanTech

If you use your own VPN try making a new PKI with the correct settings.

EastRSA comes with default settings which should be fully compatible, let us know how it goes.

If you are using a public VPN Service tell them their certificate bundle is out of date.

ordex

Can you also make sure certificates, CA and CRL (if used) are not expired? What is the exact message reported in the log?
Generally speaking, mbedTLS is simply trying to stick to the currently non-broken settings (whatever they are - which means not just the signature algorithm), therefore it's very possible that you are using something outdated.
The solution recommended by tincantech is probably the one that would take you to a safe spot.

ordex

openwhat wrote Same here, I don't use MD5.

A few Server settings I use:

- Authorization Mode: TLS
- Extra HMAC authorization (tls-auth / tls-crypt): Incoming Auth (0)
- Legacy/fallback cipher: AES-128-CBC
- Auth digest: SHA1
- Compression: LZO

This is your VPN configuration. When I mentioned MD5 I referred to the algorithm used to sign your certificates by your CA.

openwhat

Thanks for the help gents!
It's all working now with OpenVPN Connect for Android 1.1.23

I grabbed the new EasyRSA (3.0.3) and generated all new certs and keys.
When I compared with the old stuff it seems I indeed used Server and Client certs with MD5 signature hash-algorithm.
The new generated certs are all sha256.

Problem solved.

openwhat

Oh, one more question.

It seems client download speed has dropped a bit.
From approx. 18 Mbps to 11 Mbps.
I didn't change anything in the VPN config, only new certificates and keys.

Is this as expected? (Increased CPU load because of new certs and keys.)

gkuenning

TinCanTech wrote If you use your own VPN try making a new PKI with the correct settings.

EastRSA comes with default settings which should be fully compatible, let us know how it goes.

If you are using a public VPN Service tell them their certificate bundle is out of date.

You're joking, right? I should redeploy the entire VPN because of this bug?

gkuenning

ordex wrote
openwhat wrote Same here, I don't use MD5.

A few Server settings I use:

- Authorization Mode: TLS
- Extra HMAC authorization (tls-auth / tls-crypt): Incoming Auth (0)
- Legacy/fallback cipher: AES-128-CBC
- Auth digest: SHA1
- Compression: LZO
This is your VPN configuration. When I mentioned MD5 I referred to the algorithm used to sign your certificates by your CA.

Yes but I already posted evidence from my own certificate, which uses SHA1.

ordex

gkuenning wrote Yes but I already posted evidence from my own certificate, which uses SHA1.

I believe I have missed that. Was it here in this thread? If your cert is signed with SHA1 there might be something different to look at. IT would be interesting to inspect the cert and CA.

dazo

Just to clarify one important detail, as I'm not sure if there is a confusion or not.

- Auth digest: SHA1

This line does NOT mean the certificate is not signed using an MD5 based signature.

Please check the output of:

    $ openssl x509 -in $CERTIFICATE_FILE -noout -text | grep "Signature Algorithm"

Make sure you check the CA certificate, as well as the server and client certificates.

And regarding ...

You're joking, right? I should redeploy the entire VPN because of this bug?

If you are using MD5 certificates, you should definitely do exactly that. More details can be found in these few tweets from the @OpenVPN account: https://twitter.com/OpenVPN/status/899604229240877056

dazo

openwhat wrote Oh, one more question.

It seems client download speed has dropped a bit.
From approx. 18 Mbps to 11 Mbps.
I didn't change anything in the VPN config, only new certificates and keys.

Is this as expected? (Increased CPU load because of new certs and keys.)

That seems to be a bit too much drop, to be honest. But there are many factors influencing the throughput. The certificate's public key length plays a role to a certain degree, but that is only used when establishing the session encryption keys for the tunnelled network traffic. But a few hints are to look at what kind of --cipher and --auth algorithm you use. Those have a far more massive impact - when otherwise ignoring the link quality between the client and server. By the way, which version does your OpenVPN server run?

Prefer GCM based ciphers if you can, as that gives the least packet overhead and does decryption and packet authentication in a single crypto operation. if you need to use a CBC based cipher, you should use --auth SHA1 (default) or --auth SHA256. Using SHA1 for --auth is considered safe, as SHA1 have no known cryptographic weaknesses when doing HMAC operations. SHA1 adds 20 bytes to each packet sent over the Internet link. SHA256 adds 32 bytes. And if you use SHA512, that adds 64(!) bytes and does not give any real security gain over SHA256.

gkuenning

dazo wrote Just to clarify one important detail, as I'm not sure if there is a confusion or not.

- Auth digest: SHA1
This line does NOT mean the certificate is not signed using an MD5 based signature.

Please check the output of:
    $ openssl x509 -in $CERTIFICATE_FILE -noout -text | grep "Signature Algorithm"
Make sure you check the CA certificate, as well as the server and client certificates.

That's the issue. I only checked my CA certificate; the server has an MD5 certificate.

And regarding ...
You're joking, right? I should redeploy the entire VPN because of this bug?
If you are using MD5 certificates, you should definitely do exactly that. More details can be found in these few tweets from the @OpenVPN account: https://twitter.com/OpenVPN/status/899604229240877056

That depends entirely on why one is using a VPN. I don't give a hoot about encryption quality, and very little about the risk of strangers joining my VPN. For me it's all about routing.

Nevertheless I'll probably upgrade over the holidays when I have access to all the machines involved.

TinCanTech

gkuenning wrote
TinCanTech wrote If you use your own VPN try making a new PKI with the correct settings.

EastRSA comes with default settings which should be fully compatible, let us know how it goes.

If you are using a public VPN Service tell them their certificate bundle is out of date.
You're joking, right? I should redeploy the entire VPN because of this bug?

It is not a bug .. And it is your PKI not your VPN.

gkuenning wrote Unfortunately it fails even if you don't use MD5. My certificate is 1024-bit RSA, SHA1 with RSA encryption as the signature algorithm. And 1.1.23 doesn't work. 1.1.17 does.

It doesn't work because your certificate not up to scratch with modern security ..

gkuenning wrote That depends entirely on why one is using a VPN. I don't give a hoot about encryption quality, and very little about the risk of strangers joining my VPN. For me it's all about routing.

Everyone else is concerned about their security .. It is the P in V.P.N.

There are two parts to Openvpn .. the network side and the security side ..
The network side is a work of art when you understand how it is done.

The security side is almost but not completely down to the SSL Library in use ..
Many decisions regarding it's implementation are resolved upstream not by OpenVPN.

ch-ch-ch-ch-Changes :cry:

ordex

gkuenning wrote
dazo wrote Just to clarify one important detail, as I'm not sure if there is a confusion or not.

- Auth digest: SHA1
This line does NOT mean the certificate is not signed using an MD5 based signature.

Please check the output of:
    $ openssl x509 -in $CERTIFICATE_FILE -noout -text | grep "Signature Algorithm"
Make sure you check the CA certificate, as well as the server and client certificates.
That's the issue. I only checked my CA certificate; the server has an MD5 certificate.

And regarding ...
You're joking, right? I should redeploy the entire VPN because of this bug?
If you are using MD5 certificates, you should definitely do exactly that. More details can be found in these few tweets from the @OpenVPN account: https://twitter.com/OpenVPN/status/899604229240877056
That depends entirely on why one is using a VPN. I don't give a hoot about encryption quality, and very little about the risk of strangers joining my VPN. For me it's all about routing.

Nevertheless I'll probably upgrade over the holidays when I have access to all the machines involved.

There is a beta release on PlayStore (1.1.24 build 93) that is expected to support MD5 again. Would you mind giving it a shot and let us know if that works?

YUChoe

1.1.24 works again for me. Thanks! Good job 🙂

ordex

Yeah, the beta release is out live. MD5 is supported again.
Please have a look at the changelog: in 6 months MD5 will be definitely dropped, thus this is the time to act and get rid of broken algorithms! 🙂

gkuenning

I always gotta love the "We know better than you, so we're going to force you to change even though we don't understand your use case" attitude.

Sigh.

I cannot being to count the number of perfectly acceptable applications and services that have stopped working for me because somebody thinks they should be my parent. Not to mention the number of hours I've wasted working around this nanny-ism.

It's one thing to say "We recommend really strongly that you do X, for very good reasons Y." I've often--in fact, nearly always--made configuration changes as a result of such suggestions. But it's quite another to say "You MUST do X because we lack the imagination to see that there are reasons where X is either unnecessary or downright inappropriate."

[deleted]

dazo wrote Just to clarify one important detail, as I'm not sure if there is a confusion or not.

- Auth digest: SHA1
This line does NOT mean the certificate is not signed using an MD5 based signature.

Please check the output of:
    $ openssl x509 -in $CERTIFICATE_FILE -noout -text | grep "Signature Algorithm"
Make sure you check the CA certificate, as well as the server and client certificates.

And regarding ...
You're joking, right? I should redeploy the entire VPN because of this bug?
If you are using MD5 certificates, you should definitely do exactly that. More details can be found in these few tweets from the @OpenVPN account: https://twitter.com/OpenVPN/status/899604229240877056

dazo,

I need help. Can you help me?

« Previous Page Next Page »