OpenVPN '--ns-cert-type' is deprecated

Help on building IPFire & Feature Requests
ummeegge
Community Developer
Community Developer
Posts: 4215
Joined: October 9th, 2010, 10:00 am

OpenVPN '--ns-cert-type' is deprecated

Post by ummeegge » June 9th, 2017, 1:37 pm

Hi all,
since later OpenVPN-2.3+ versions the following message appears in the client connection logs:

Code: Select all

WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
i have searched a little around to find a solution for this.
The OpenVPN 2.3 manpages --> https://community.openvpn.net/openvpn/w ... n23ManPage points the following out:
--ns-cert-type client|server
Require that peer certificate was signed with an explicit nsCertType designation of "client" or "server".

This is a useful security option for clients, to ensure that the host they connect with is a designated server.

See the easy-rsa/build-key-server script for an example of how to generate a certificate with the nsCertType field set to "server".

If the server certificate's nsCertType field is set to "server", then the clients can verify this with --ns-cert-type server.

This is an important security precaution to protect against a man-in-the-middle attack where an authorized client attempts to connect to another client by impersonating the server. The attack is easily prevented by having clients verify the server certificate using any one of --ns-cert-type, --verify-x509-name, or --tls-verify.
and for --remote-cert-tls:
--remote-cert-tls client|server
Require that peer certificate was signed with an explicit key usage and extended key usage based on RFC3280 TLS rules.

This is a useful security option for clients, to ensure that the host they connect to is a designated server.

The --remote-cert-tls client option is equivalent to --remote-cert-ku 80 08 88 --remote-cert-eku "TLS Web Client Authentication"

The key usage is digitalSignature and/or keyAgreement.

The --remote-cert-tls server option is equivalent to --remote-cert-ku a0 88 --remote-cert-eku "TLS Web Server Authentication"

The key usage is digitalSignature and ( keyEncipherment or keyAgreement ).

This is an important security precaution to protect against a man-in-the-middle attack where an authorized client attempts to connect to another client by impersonating the server. The attack is easily prevented by having clients verify the server certificate using any one of --remote-cert-tls, --verify-x509-name, or --tls-verify.
whereby the OpenVPN 2.4 manpage --> https://community.openvpn.net/openvpn/w ... n24ManPage gives the deprecation warning:
--ns-cert-type client|server (DEPRECATED)
This option is deprecated. Use the more modern equivalent --remote-cert-tls instead. This option will be removed in OpenVPN 2.5.
Since i try currently to integrate OpenVPN-2.4.2 into IPFire environment --> https://forum.ipfire.org/viewtopic.php?f=50&t=18067 i do see a little urgency to stay compatible in a not so far away future (OpenVPN-2.5.x) without the hassle to regenerate a lot´s of certificates cause "they need to, now"...

A possible solution (the only one i could find until now):
To stay compliant to RFC3280 TLS rules --> https://www.ietf.org/rfc/rfc3280.txt IPFire misses the respective OpenSSL configuration entries.
The diff for the OpenSSL configuration file (findable under /var/ipfire/ovpn/openssl/ovpn.cnf) for OpenVPN can looks like this:

Code: Select all

--- /var/ipfire/ovpn/openssl/ovpn.cnf.orig	2017-06-09 13:17:22.431163012 +0200
+++ /var/ipfire/ovpn/openssl/ovpn.cnf	2017-06-09 15:07:25.831784061 +0200
@@ -77,6 +77,10 @@
 nsComment			= "OpenSSL Generated Certificate"
 subjectKeyIdentifier		= hash
 authorityKeyIdentifier		= keyid,issuer:always
+# Needed for --remote-cert-tls
+extendedKeyUsage		= clientAuth
+keyUsage 			= digitalSignature
+#
 
 [ server ]
 
@@ -86,6 +90,10 @@
 nsComment			= "OpenSSL Generated Server Certificate"
 subjectKeyIdentifier		= hash
 authorityKeyIdentifier		= keyid,issuer:always 
+# Needed for --remote-cert-tls
+extendedKeyUsage		= serverAuth
+keyUsage 			= digitalSignature, keyEncipherment
+#
 
 [ v3_req ]
 basicConstraints 		= CA:FALSE
Since IPFires current host certificate do not includes

Code: Select all

            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment
the problem appears that all existing clients rely on the deprecated "Netscape" cert attribute which uses the '--ns-cert-type server' directive. IPFire´s host certificate (in that way the root certificate too) needs to be regenerated with the new defined key usage extension entries, changing only the client.conf directives (from '--ns-cert-type server' to '--remote-cert-tls server' ) won´t work and ends up in a

Code: Select all

Fri Jun  9 13:42:41 2017 Certificate does not have key usage extension
Fri Jun  9 13:42:41 2017 VERIFY KU ERROR
Fri Jun  9 13:42:41 2017 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Fri Jun  9 13:42:41 2017 TLS_ERROR: BIO read tls_read_plaintext error
Fri Jun  9 13:42:41 2017 TLS Error: TLS object -> incoming plaintext read error
Fri Jun  9 13:42:41 2017 TLS Error: TLS handshake failed
If the new OpenSSL parameter has been set and new clients are generated with the new host certificate, both directives ('--ns-cert-type server' and '--remote-cert-tls server') can be used in client.ovpn. Whereby if the '--remote-cert-tls server' directive takes place in the client.ovpn the following client log entries appears:

Code: Select all

Fri Jun  9 14:10:54 2017 VERIFY OK: depth=1, C=DE, O=test, CN=test CA
Fri Jun  9 14:10:54 2017 VERIFY KU OK
Fri Jun  9 14:10:54 2017 Validating certificate extended key usage
Fri Jun  9 14:10:54 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Jun  9 14:10:54 2017 VERIFY EKU OK
All that seems like this are not so good news (smells like work :-( ), nevertheless i wanted to make a remark in the forum (too).

May someone knows better solutions for that (i call it) problem ? May someone have other better ideas for a new ovpn.cnf ? And for sure if someone wants to test this too, feedback (as usual) might be great.

Greetings,

UE
Image
Image
Image

fkienker
Posts: 76
Joined: March 3rd, 2011, 4:59 pm

Re: OpenVPN '--ns-cert-type' is deprecated

Post by fkienker » June 12th, 2017, 4:06 pm

Thanks so much for doing the investigation on this! Time (and software) marches on and being prepared is far better than being surprised.

Fred

ummeegge
Community Developer
Community Developer
Posts: 4215
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN '--ns-cert-type' is deprecated

Post by ummeegge » June 12th, 2017, 7:18 pm

Hi Fred,
thanks for your positiv feedback.
fkienker wrote:Time (and software) marches on and being prepared is far better than being surprised.
This is exactly my point in here (same in the 2.4 development (arrangement)) whereby it might be nice if there can be made some good preparations for all that upcoming changes with as much if´s and elif´s, ..., in there as possible ;-) .

It might be interesting if e.g. iOS or Android´s can handle '--remote-cert-tls' , since i do not use smart?phones may someone comes along which knows more about that...

Best regards,

UE
Image
Image
Image

ummeegge
Community Developer
Community Developer
Posts: 4215
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN '--ns-cert-type' is deprecated

Post by ummeegge » June 16th, 2017, 8:31 pm

Have pushed now a first idea to Git which includes:

- Extended key usage based on RFC3280 TLS rules for OpenVPNs OpenSSL configuration,
so '--remote-cert-tls server' can be used instead of the old and deprecated '--ns-cert-type server' if the host certificate (Root certificate by the way too) are newly generated with this options.
Nevertheless both directives should work also with new certificates.

Since i do not wanted to make those directives configurable over the webinterface (makes only confusion) i thought it might be a nice idea if the CGI do this by itself. So i added a

- Automatic detection in ovpnmain.cgi if the host certificate uses the new options.
If it does, '--remote-cert-tls server' will be automatically set into the client
configurations for N2N and RW.
If it does NOT, the old '--ns-cert-type server' directive will be set in the client
configurations for N2N and RW.

The patched files can be found in here --> http://git.ipfire.org/?p=people/ummeegg ... dceb3b3e53 .

Please give them some testings :P .

Thanks and greetings,

UE

EDIT: Interesting topics causing the smart?phone thing:
- https://github.com/schwabe/ics-openvpn/issues/168
- https://forums.openvpn.net/viewtopic.php?t=19382
Image
Image
Image

fkienker
Posts: 76
Joined: March 3rd, 2011, 4:59 pm

Re: OpenVPN '--ns-cert-type' is deprecated

Post by fkienker » June 19th, 2017, 4:09 pm

[quote="ummeegge"]Have pushed now a first idea to Git which includes:

- Extended key usage based on RFC3280 TLS rules for OpenVPNs OpenSSL configuration,
so '--remote-cert-tls server' can be used instead of the old and deprecated '--ns-cert-type server' if the host certificate (Root certificate by the way too) are newly generated with this options.
Nevertheless both directives should work also with new certificates.

Really like this idea and you seem to have implemented it in a very convenient fashion. As soon as we get our test box restored (yes, we blew it up which is what a test box is for) I will add this, generate new certs, and try it out.

Thanks in advance!
Fred

User avatar
H&M
Posts: 379
Joined: May 29th, 2014, 9:38 pm
Location: Europe

Re: OpenVPN '--ns-cert-type' is deprecated

Post by H&M » June 28th, 2017, 5:47 pm

Hi,

My Android just updated OpenVPN client ...client uses latest OpenSSL 1.1.0f and fails to authenticate IPFire cert

Errors - client log

Code: Select all

OpenVPN 2.5-icsopenvpn [git:icsopenvpn-d51333c645c12713+] android-14-armeabi-v7a [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jun 26 2017
ibrary versions: OpenSSL 1.1.0f  25 May 2017, LZO 2.10
---
WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
---
OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed

Errors - OpenVPN/IPfire logs

Code: Select all

TLS: Initial packet from [AF_INET]a.b.101.103:2430, sid=6b0e1336 7db128e2
Connection reset, restarting [0]
SIGUSR1[soft,connection-reset] received, client-instance restarting
Server.conf

Code: Select all

daemon openvpnserver
writepid /var/run/openvpn.pid
#DAN prepare OpenVPN for listening on blue and orange

dev tun
proto tcp
port 1456
script-security 3 system
ifconfig-pool-persist /var/ipfire/ovpn/ovpn-leases.db 3600
client-config-dir /var/ipfire/ovpn/ccd
tls-server
ca /var/ipfire/ovpn/ca/cacert.pem
cert /var/ipfire/ovpn/certs/servercert.pem
key /var/ipfire/ovpn/certs/serverkey.pem
dh /var/ipfire/ovpn/ca/dh1024.pem
server 10.1.9.0 255.255.255.0
tun-mtu 1500
push "route a.b.1.0 255.255.255.0"
mtu-disc yes
keepalive 10 60
status-version 1
status /var/run/ovpnserver.log 30
cipher AES-256-CBC
auth SHA1
comp-lzo
push "redirect-gateway def1"
push "dhcp-option DOMAIN no-ip.biz"
push "dhcp-option DNS a.b.c.1"
max-clients 100
tls-verify /usr/lib/openvpn/verify
crl-verify /var/ipfire/ovpn/crls/cacrl.pem
user nobody
group nobody
persist-key
persist-tun
verb 3


I checked and even downloaded again all OpenVPN client config from IPFire but no use: I can't make it work again
I've commented --ns-cert-type option, activated (as recommended) remote-cert-tls but no use.

This is the only post where I found above errors - please excuse me if this is not the correct place to raise this!

Any ideas how to fix above?

Thank you,
H&M

ummeegge
Community Developer
Community Developer
Posts: 4215
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN '--ns-cert-type' is deprecated

Post by ummeegge » June 28th, 2017, 8:01 pm

Hi H&M,
i haven´t had such problem that if the client uses the old directive '--ns-cert-type server' that the server rejects the connection even it is only a warning that this directive is deprecated and not an error. But the OpenSSL error was exactly the same here if i use the new '--remote-cert-tls server ' directive with the old certificates (explanation why is below).

Otherwise this topic is exactly for that problem. I tried to describe this problem in my first post --> https://forum.ipfire.org/viewtopic.php? ... 71#p108144 at the end. Changing only the directive ended for me up in the same error message. It was not enough to change only the directive since IPFires HOST CA do not include the important key extensions. You can check this if you click on the blue info box for the "Host certificate" in this section:
-->
Image

without this entries:

Code: Select all

            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Key Usage:
                Digital Signature, Key Encipherment
-->
Image

you won´t be able to use "--remote-cert-tls" .

Needed two steps to solve this:

- The problem is that all existing clients rely on the deprecated "Netscape" cert attribute. The only way i could find out how to solve this was to delete the whole PKI ( by pressing the "Remove X509" button) whereby all existing clients can´t connect anymore and to supplement OpenVPNs OpenSSL configuration (findable under /var/ipfire/openssl/ovpn.cnf ) with the following entries -->
http://git.ipfire.org/?p=people/ummeegg ... 6361169390
after this changes, a new PKI can be generated which should include the above mentioned key extensions and have from now on RFC3280 compliant TLS rules --> https://www.ietf.org/rfc/rfc3280.txt .

- Have made a patch for the ovpnmain.cgi which checks if the needed entries are existend, if they are, it will prints the new directive into the client.ovpn. If it does not, the old "--ns-cert-type server" will be used. The diff is located in here --> http://git.ipfire.org/?p=people/ummeegg ... 6361169390 .

so every new client should have the appropriate directive automatically. With the new "TLS Web Server Authentication" the verification should looks like this:

Code: Select all

Fri Jun  9 14:10:54 2017 VERIFY OK: depth=1, C=DE, O=test, CN=test CA
Fri Jun  9 14:10:54 2017 VERIFY KU OK
Fri Jun  9 14:10:54 2017 Validating certificate extended key usage
Fri Jun  9 14:10:54 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Jun  9 14:10:54 2017 VERIFY EKU OK
But as mentioned above, all connections comes at this time up also with the old '--ns-cert-type server'. To change the whole PKI is a lot of hassle if you have a lot of clients but the OpenVPN docs tell that they won´t use this directive anymore with OpenVPN version >= 2.5.x (am currently unsure if the new OpenSSL-1.1.0 have there also a problem ??) so also for the clients which currently works, there is not that much time until then to fix this...

Greetings,

UE
Image
Image
Image

User avatar
H&M
Posts: 379
Joined: May 29th, 2014, 9:38 pm
Location: Europe

Re: OpenVPN '--ns-cert-type' is deprecated

Post by H&M » June 28th, 2017, 8:02 pm

ummeegge wrote:Hi H&M,


Needed two steps to solve this:

- The problem is that all existing clients rely on the deprecated "Netscape" cert attribute. The only way i could find out how to solve this was to delete the whole PKI ( by pressing the "Remove X509" button) whereby all existing clients can´t connect anymore and to supplement OpenVPNs OpenSSL configuration (findable under /var/ipfire/openssl/ovpn.cnf ) with the following entries -->
http://git.ipfire.org/?p=people/ummeegg ... 6361169390
after this changes, a new PKI can be generated which should include the above mentioned key extensions and have from now on RFC3280 compliant TLS rules --> https://www.ietf.org/rfc/rfc3280.txt .

- Have made a patch for the ovpnmain.cgi which checks if the needed entries are existend, if they are, it will prints the new directive into the client.ovpn. If it does not, the old "--ns-cert-type server" will be used. The diff is located in here --> http://git.ipfire.org/?p=people/ummeegg ... 6361169390 .

so every new client should have the appropriate directive automatically. With the new "TLS Web Server Authentication" the verification should looks like this:

Code: Select all

Fri Jun  9 14:10:54 2017 VERIFY OK: depth=1, C=DE, O=test, CN=test CA
Fri Jun  9 14:10:54 2017 VERIFY KU OK
Fri Jun  9 14:10:54 2017 Validating certificate extended key usage
Fri Jun  9 14:10:54 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Jun  9 14:10:54 2017 VERIFY EKU OK
This change is a lot of hassle if you have a lot of clients but OpenVPN won´t use this directive anymore with OpenVPN version >= 2.5.x so there is not that much time until then to fix this...

Greetings,

UE
Ohhh...
I only downloaded from GIT the openssl/ovpn.cnf.
I somehow missed the cgi file!

Will get that too and come back to post the result(s)!

Late edit: how can I regenerate all certificate & DH & TLS-Authentification-Key again?
Reason: I have NO TLS-Authentification-Key:... ???


Thank you,
H&M
Last edited by H&M on June 28th, 2017, 8:07 pm, edited 1 time in total.

ummeegge
Community Developer
Community Developer
Posts: 4215
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN '--ns-cert-type' is deprecated

Post by ummeegge » June 28th, 2017, 8:05 pm

Your welcome,
don´t forget to renew the PKI :) .

See you ;) .
Image
Image
Image

User avatar
H&M
Posts: 379
Joined: May 29th, 2014, 9:38 pm
Location: Europe

Re: OpenVPN '--ns-cert-type' is deprecated

Post by H&M » June 28th, 2017, 8:08 pm

ummeegge wrote:Your welcome,
don´t forget to renew the PKI :) .

See you ;) .


How can I accomplish that? :-[

ummeegge
Community Developer
Community Developer
Posts: 4215
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN '--ns-cert-type' is deprecated

Post by ummeegge » June 28th, 2017, 8:15 pm

This is the part which is not so funny :( , in here --> http://wiki.ipfire.org/en/configuration ... upload_gen you can find it at the bottom under the section "Remove X509" (after that all clients needs new certificats) you need to reload the bowser after clicking the "Remove X509" button and the OpenVPN WUI should looks similar to this --> http://wiki.ipfire.org/en/configuration ... onfig/cert . The new OpenSSL entries will then be used for the new CA...

UE
Image
Image
Image

ummeegge
Community Developer
Community Developer
Posts: 4215
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN '--ns-cert-type' is deprecated

Post by ummeegge » June 28th, 2017, 8:33 pm

LATE EDIT ANSWER:
H&M wrote:Late edit: how can I regenerate all certificate & DH & TLS-Authentification-Key again?
Reason: I have NO TLS-Authentification-Key:... ???
The certificates and the DH Param will be generated after you filled in the infos which you can see here --> http://wiki.ipfire.org/en/configuration ... onfig/cert and after clicking the "Generate Root/Host certificate" .
You can choose there also the DH-Parameter length but be careful, long lengths needs very long time. It might be better to upload an external generated DH-Parameter (may generated on your admin machine) like described in here --> http://wiki.ipfire.org/en/configuration ... upload_gen under "Diffie-Hellman-Parameter options". 1024 bit goes quick but is really not suggested, 2048 bit takes longer but should be OK in terms of generation time and also in security aspects. You can re-upload also later a longer Diffie-Hellman parameter.
Your TLS-Auth key will be generated if you tick the checkbox in the "Advanced server options" section --> http://wiki.ipfire.org/en/configuration ... vanced_set <-- described at the bottom --> before you create new clients.
Image
Image
Image

User avatar
H&M
Posts: 379
Joined: May 29th, 2014, 9:38 pm
Location: Europe

Re: OpenVPN '--ns-cert-type' is deprecated

Post by H&M » June 28th, 2017, 9:08 pm

Hi,

Removed all CA/DH.
Generated new ones.
Copied files from GIT.
Generated new client certificate.

All works like a charm!
UE OpenVPN with newCA .PNG
Thank you!
H&M

ummeegge
Community Developer
Community Developer
Posts: 4215
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN '--ns-cert-type' is deprecated

Post by ummeegge » June 28th, 2017, 9:29 pm

Am happy to read this :) ,
but i am also concerned causing your beginning statement that the connection won´t come up with the old directive and i´ am currently unsure why that´s happening. My old connections (have currently some of them with old certs but also older OpenSSL libs {1.0.2g{l}}, but also the new OpenVPN-2.4.3) do make their warnings causing --ns-cert-type and it´s deprecation but they can connect...
My suspicious is the new OpenSSL-1.1.0 lib cause OpenVPNs deadline with this directive is 2.5.x so from this side it should be OK...

One more thing is great with your contribution, we have a testing result from an Android user :D . Is it possible for you to attach a connection log from your Android, which OpenVPN version did you used on your device and some software details ? This might be great and surely a help for others.

Greetings,

UE
Image
Image
Image

User avatar
H&M
Posts: 379
Joined: May 29th, 2014, 9:38 pm
Location: Europe

Re: OpenVPN '--ns-cert-type' is deprecated

Post by H&M » June 28th, 2017, 9:47 pm

ummeegge wrote:
One more thing is great with your contribution, we have a testing result from an Android user :D . Is it possible for you to attach a connection log from your Android, which OpenVPN version did you used on your device and some software details ? This might be great and surely a help for others.

Greetings,

UE

Here are the info:

Android 6.0 Marshmallow with OpenVPN official build 0.6.73, android is not rooted.
The client uses library versions: OpenSSL 1.1.0f 25 May 2017, LZO 2.10
IPfire is core 111 i586.

Client log:

Code: Select all

2017-06-29 00:33:42 official build 0.6.73 running on lge LG-D855 (MSM8974), Android 6.0 (MRA58K) API 23, ABI armeabi-v7a, (lge/g3_global_com/g3:6.0/MRA58K/162291543a76c:user/release-keys)
2017-06-29 00:33:42 Building configuration…
2017-06-29 00:33:42 New OpenVPN Status (VPN_GENERATE_CONFIG->LEVEL_START): 
2017-06-29 00:33:42 New OpenVPN Status (VPN_GENERATE_CONFIG->LEVEL_START): 
2017-06-29 00:33:42 started Socket Thread
2017-06-29 00:33:42 Network Status: CONNECTED HSPA+ to MOBILE 
2017-06-29 00:33:42 Debug state info: CONNECTED HSPA+ to MOBILE , pause: userPause, shouldbeconnected: true, network: SHOULDBECONNECTED 
2017-06-29 00:33:42 Debug state info: CONNECTED HSPA+ to MOBILE , pause: userPause, shouldbeconnected: true, network: SHOULDBECONNECTED 
2017-06-29 00:33:42 P:Initializing Google Breakpad!
2017-06-29 00:33:42 Current Parameter Settings:
2017-06-29 00:33:42   config = '/data/user/10/de.blinkt.openvpn/cache/android.conf'
2017-06-29 00:33:42   mode = 0
2017-06-29 00:33:42   show_ciphers = DISABLED
2017-06-29 00:33:42   show_digests = DISABLED
2017-06-29 00:33:42   show_engines = DISABLED
2017-06-29 00:33:42   genkey = DISABLED
2017-06-29 00:33:42   key_pass_file = '[UNDEF]'
2017-06-29 00:33:42 Waiting 0s seconds between connection attempt
2017-06-29 00:33:42   show_tls_ciphers = DISABLED
2017-06-29 00:33:42   connect_retry_max = 0
2017-06-29 00:33:42 Connection profiles [0]:
2017-06-29 00:33:42   proto = tcp-client
2017-06-29 00:33:42   local = '[UNDEF]'
2017-06-29 00:33:42   local_port = '[UNDEF]'
2017-06-29 00:33:42   remote = 'ipfire.no-ip.biz'
2017-06-29 00:33:42   remote_port = 'wxyz'
2017-06-29 00:33:42   remote_float = DISABLED
2017-06-29 00:33:42   bind_defined = DISABLED
2017-06-29 00:33:42   bind_local = DISABLED
2017-06-29 00:33:42   bind_ipv6_only = DISABLED
2017-06-29 00:33:42   connect_retry_seconds = 2
2017-06-29 00:33:42   connect_timeout = 120
2017-06-29 00:33:42   socks_proxy_server = '[UNDEF]'
2017-06-29 00:33:42   socks_proxy_port = '[UNDEF]'
2017-06-29 00:33:42   tun_mtu = 1500
2017-06-29 00:33:42   tun_mtu_defined = ENABLED
2017-06-29 00:33:42   link_mtu = 1500
2017-06-29 00:33:42   link_mtu_defined = DISABLED
2017-06-29 00:33:42   tun_mtu_extra = 0
2017-06-29 00:33:42   tun_mtu_extra_defined = DISABLED
2017-06-29 00:33:42   mtu_discover_type = -1
2017-06-29 00:33:42   fragment = 0
2017-06-29 00:33:42   mssfix = 1450
2017-06-29 00:33:42   explicit_exit_notification = 0
2017-06-29 00:33:42 Connection profiles END
2017-06-29 00:33:42   remote_random = DISABLED
2017-06-29 00:33:42   ipchange = '[UNDEF]'
2017-06-29 00:33:42   dev = 'tun'
2017-06-29 00:33:42   dev_type = '[UNDEF]'
2017-06-29 00:33:42   dev_node = '[UNDEF]'
2017-06-29 00:33:42   lladdr = '[UNDEF]'
2017-06-29 00:33:42   topology = 1
2017-06-29 00:33:42   ifconfig_local = '[UNDEF]'
2017-06-29 00:33:42   ifconfig_remote_netmask = '[UNDEF]'
2017-06-29 00:33:42   ifconfig_noexec = DISABLED
2017-06-29 00:33:42   ifconfig_nowarn = ENABLED
2017-06-29 00:33:42   ifconfig_ipv6_local = '[UNDEF]'
2017-06-29 00:33:42   ifconfig_ipv6_netbits = 0
2017-06-29 00:33:42   ifconfig_ipv6_remote = '[UNDEF]'
2017-06-29 00:33:42   shaper = 0
2017-06-29 00:33:42   mtu_test = 0
2017-06-29 00:33:42   mlock = DISABLED
2017-06-29 00:33:42   keepalive_ping = 0
2017-06-29 00:33:42   keepalive_timeout = 0
2017-06-29 00:33:42   inactivity_timeout = 0
2017-06-29 00:33:42   ping_send_timeout = 0
2017-06-29 00:33:42   ping_rec_timeout = 0
2017-06-29 00:33:42   ping_rec_timeout_action = 0
2017-06-29 00:33:42   ping_timer_remote = DISABLED
2017-06-29 00:33:42   remap_sigusr1 = 0
2017-06-29 00:33:42   persist_tun = DISABLED
2017-06-29 00:33:42   persist_local_ip = DISABLED
2017-06-29 00:33:42   persist_remote_ip = DISABLED
2017-06-29 00:33:42   persist_key = DISABLED
2017-06-29 00:33:42   passtos = DISABLED
2017-06-29 00:33:42   resolve_retry_seconds = 60
2017-06-29 00:33:42   resolve_in_advance = DISABLED
2017-06-29 00:33:42   username = '[UNDEF]'
2017-06-29 00:33:42   groupname = '[UNDEF]'
2017-06-29 00:33:42   chroot_dir = '[UNDEF]'
2017-06-29 00:33:42   cd_dir = '[UNDEF]'
2017-06-29 00:33:42   writepid = '[UNDEF]'
2017-06-29 00:33:42   up_script = '[UNDEF]'
2017-06-29 00:33:42   down_script = '[UNDEF]'
2017-06-29 00:33:42   down_pre = DISABLED
2017-06-29 00:33:42   up_restart = DISABLED
2017-06-29 00:33:42   up_delay = DISABLED
2017-06-29 00:33:42   daemon = DISABLED
2017-06-29 00:33:42   inetd = 0
2017-06-29 00:33:42   log = DISABLED
2017-06-29 00:33:42   suppress_timestamps = DISABLED
2017-06-29 00:33:42   machine_readable_output = ENABLED
2017-06-29 00:33:42   nice = 0
2017-06-29 00:33:42   verbosity = 4
2017-06-29 00:33:42   mute = 0
2017-06-29 00:33:42   gremlin = 0
2017-06-29 00:33:42   status_file = '[UNDEF]'
2017-06-29 00:33:42   status_file_version = 1
2017-06-29 00:33:42   status_file_update_freq = 60
2017-06-29 00:33:42   occ = ENABLED
2017-06-29 00:33:42   rcvbuf = 0
2017-06-29 00:33:42   sndbuf = 0
2017-06-29 00:33:42   sockflags = 0
2017-06-29 00:33:42   fast_io = DISABLED
2017-06-29 00:33:42   comp.alg = 2
2017-06-29 00:33:42   comp.flags = 1
2017-06-29 00:33:42   route_script = '[UNDEF]'
2017-06-29 00:33:42   route_default_gateway = '[UNDEF]'
2017-06-29 00:33:42   route_default_metric = 0
2017-06-29 00:33:42   route_noexec = DISABLED
2017-06-29 00:33:42   route_delay = 0
2017-06-29 00:33:42   route_delay_window = 30
2017-06-29 00:33:42   route_delay_defined = DISABLED
2017-06-29 00:33:42   route_nopull = DISABLED
2017-06-29 00:33:42   route_gateway_via_dhcp = DISABLED
2017-06-29 00:33:42   allow_pull_fqdn = DISABLED
2017-06-29 00:33:42   management_addr = '/data/user/10/de.blinkt.openvpn/cache/mgmtsocket'
2017-06-29 00:33:42   management_port = 'unix'
2017-06-29 00:33:42   management_user_pass = '[UNDEF]'
2017-06-29 00:33:42   management_log_history_cache = 250
2017-06-29 00:33:42   management_echo_buffer_size = 100
2017-06-29 00:33:42   management_write_peer_info_file = '[UNDEF]'
2017-06-29 00:33:42   management_client_user = '[UNDEF]'
2017-06-29 00:33:42   management_client_group = '[UNDEF]'
2017-06-29 00:33:42   management_flags = 4390
2017-06-29 00:33:42   shared_secret_file = '[UNDEF]'
2017-06-29 00:33:42   key_direction = (null)
2017-06-29 00:33:42   ciphername = 'AES-256-CBC'
2017-06-29 00:33:42   ncp_enabled = ENABLED
2017-06-29 00:33:42   ncp_ciphers = 'AES-256-GCM:AES-128-GCM'
2017-06-29 00:33:42   authname = 'SHA1'
2017-06-29 00:33:42   prng_hash = 'SHA1'
2017-06-29 00:33:42   prng_nonce_secret_len = 16
2017-06-29 00:33:42   keysize = 0
2017-06-29 00:33:42   engine = DISABLED
2017-06-29 00:33:42   replay = ENABLED
2017-06-29 00:33:42   mute_replay_warnings = DISABLED
2017-06-29 00:33:42   replay_window = 64
2017-06-29 00:33:42   replay_time = 15
2017-06-29 00:33:42   packet_id_file = '[UNDEF]'
2017-06-29 00:33:42   test_crypto = DISABLED
2017-06-29 00:33:42   tls_server = DISABLED
2017-06-29 00:33:42   tls_client = ENABLED
2017-06-29 00:33:42   key_method = 2
2017-06-29 00:33:42   ca_file = '[[INLINE]]'
2017-06-29 00:33:42   ca_path = '[UNDEF]'
2017-06-29 00:33:42   dh_file = '[UNDEF]'
2017-06-29 00:33:42   cert_file = '[[INLINE]]'
2017-06-29 00:33:42   extra_certs_file = '[UNDEF]'
2017-06-29 00:33:42   priv_key_file = '[[INLINE]]'
2017-06-29 00:33:42   pkcs12_file = '[UNDEF]'
2017-06-29 00:33:42   cipher_list = '[UNDEF]'
2017-06-29 00:33:42   tls_verify = '[UNDEF]'
2017-06-29 00:33:43   tls_export_cert = '[UNDEF]'
2017-06-29 00:33:43   verify_x509_type = 2
2017-06-29 00:33:43   verify_x509_name = 'ipfire.no-ip.biz'
2017-06-29 00:33:43   crl_file = '[UNDEF]'
2017-06-29 00:33:43   ns_cert_type = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 65535
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_ku[i] = 0
2017-06-29 00:33:43   remote_cert_eku = 'TLS Web Server Authentication'
2017-06-29 00:33:43   ssl_flags = 0
2017-06-29 00:33:43   tls_timeout = 2
2017-06-29 00:33:43   renegotiate_bytes = -1
2017-06-29 00:33:43   renegotiate_packets = 0
2017-06-29 00:33:43   renegotiate_seconds = 3600
2017-06-29 00:33:43   handshake_window = 60
2017-06-29 00:33:43   transition_window = 3600
2017-06-29 00:33:43   single_session = DISABLED
2017-06-29 00:33:43   push_peer_info = DISABLED
2017-06-29 00:33:43   tls_exit = DISABLED
2017-06-29 00:33:43   tls_auth_file = '[UNDEF]'
2017-06-29 00:33:43   tls_crypt_file = '[UNDEF]'
2017-06-29 00:33:43   client = ENABLED
2017-06-29 00:33:43   pull = ENABLED
2017-06-29 00:33:43   auth_user_pass_file = '[UNDEF]'
2017-06-29 00:33:43 OpenVPN 2.5-icsopenvpn [git:icsopenvpn-d51333c645c12713+] android-14-armeabi-v7a [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jun 26 2017
2017-06-29 00:33:43 library versions: OpenSSL 1.1.0f  25 May 2017, LZO 2.10
2017-06-29 00:33:43 MANAGEMENT: Connected to management server at /data/user/10/de.blinkt.openvpn/cache/mgmtsocket
2017-06-29 00:33:43 MANAGEMENT: CMD 'hold release'
2017-06-29 00:33:43 MANAGEMENT: CMD 'bytecount 2'
2017-06-29 00:33:43 MANAGEMENT: CMD 'proxy NONE'
2017-06-29 00:33:43 MANAGEMENT: CMD 'state on'
2017-06-29 00:33:43 LZO compression initializing
2017-06-29 00:33:43 New OpenVPN Status (RESOLVE->LEVEL_CONNECTING_NO_SERVER_REPLY_YET): ,,,,,
2017-06-29 00:33:43 New OpenVPN Status (RESOLVE->LEVEL_CONNECTING_NO_SERVER_REPLY_YET): ,,,,,
2017-06-29 00:33:43 Control Channel MTU parms [ L:1624 D:1210 EF:40 EB:0 ET:0 EL:3 ]
2017-06-29 00:33:43 MANAGEMENT: >STATE:1498685623,RESOLVE,,,,,,
2017-06-29 00:33:43 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ]
2017-06-29 00:33:43 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
2017-06-29 00:33:43 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
2017-06-29 00:33:43 TCP/UDP: Preserving recently used remote address: [AF_INET]a.b.c.d:wxyz
2017-06-29 00:33:43 New OpenVPN Status (TCP_CONNECT->LEVEL_CONNECTING_NO_SERVER_REPLY_YET): ,,,,,
2017-06-29 00:33:44 New OpenVPN Status (TCP_CONNECT->LEVEL_CONNECTING_NO_SERVER_REPLY_YET): ,,,,,
2017-06-29 00:33:43 Socket Buffers: R=[244668->244668] S=[140625->140625]
2017-06-29 00:33:44 Attempting to establish TCP connection with [AF_INET]a.b.c.d:wxyz [nonblock]
2017-06-29 00:33:44 MANAGEMENT: >STATE:1498685623,TCP_CONNECT,,,,,,
2017-06-29 00:33:44 MANAGEMENT: CMD 'needok 'PROTECTFD' ok'
2017-06-29 00:33:45 TCP connection established with [AF_INET]a.b.c.d:wxyz
2017-06-29 00:33:45 New OpenVPN Status (WAIT->LEVEL_CONNECTING_NO_SERVER_REPLY_YET): ,,,,,
2017-06-29 00:33:45 New OpenVPN Status (WAIT->LEVEL_CONNECTING_NO_SERVER_REPLY_YET): ,,,,,
2017-06-29 00:33:45 MANAGEMENT: CMD 'needok 'PROTECTFD' ok'
2017-06-29 00:33:45 TCP_CLIENT link local: (not bound)
2017-06-29 00:33:45 TCP_CLIENT link remote: [AF_INET]a.b.c.d:wxyz
2017-06-29 00:33:45 MANAGEMENT: >STATE:1498685625,WAIT,,,,,,
2017-06-29 00:33:45 New OpenVPN Status (AUTH->LEVEL_CONNECTING_SERVER_REPLIED): ,,,,,
2017-06-29 00:33:45 New OpenVPN Status (AUTH->LEVEL_CONNECTING_SERVER_REPLIED): ,,,,,
2017-06-29 00:33:45 MANAGEMENT: >STATE:1498685625,AUTH,,,,,,
2017-06-29 00:33:45 TLS: Initial packet from [AF_INET]a.b.c.d:wxyz, sid=4a5b9a2a c299f6e5
2017-06-29 00:33:45 VERIFY OK: depth=1, C=US, L=Freetown, O=XXXXX, OU=YYYYY, CN=XXXXX CA, emailAddress=********@opayq.com
2017-06-29 00:33:45 VERIFY KU OK
2017-06-29 00:33:45 Validating certificate extended key usage
2017-06-29 00:33:45 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2017-06-29 00:33:45 VERIFY EKU OK
2017-06-29 00:33:45 VERIFY X509NAME OK: C=US, O=XXXXX, OU=YYYYY, CN=ipfire.no-ip.biz
2017-06-29 00:33:45 VERIFY OK: depth=0, C=US, O=XXXXX, OU=YYYYY, CN=ipfire.no-ip.biz
2017-06-29 00:33:46 Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
2017-06-29 00:33:46 [ipfire.no-ip.biz] Peer Connection Initiated with [AF_INET]a.b.c.d:wxyz
2017-06-29 00:33:46 Key [AF_INET]a.b.c.d:wxyz [0] not initialized (yet), dropping packet.
2017-06-29 00:33:47 New OpenVPN Status (GET_CONFIG->LEVEL_CONNECTING_SERVER_REPLIED): ,,,,,
2017-06-29 00:33:47 New OpenVPN Status (GET_CONFIG->LEVEL_CONNECTING_SERVER_REPLIED): ,,,,,
2017-06-29 00:33:47 MANAGEMENT: >STATE:1498685627,GET_CONFIG,,,,,,
2017-06-29 00:33:47 SENT CONTROL [ipfire.no-ip.biz]: 'PUSH_REQUEST' (status=1)
2017-06-29 00:33:47 New OpenVPN Status (ASSIGN_IP->LEVEL_CONNECTING_SERVER_REPLIED): ,10.10.99.6,,,,
2017-06-29 00:33:47 New OpenVPN Status (ASSIGN_IP->LEVEL_CONNECTING_SERVER_REPLIED): ,10.10.99.6,,,,
2017-06-29 00:33:47 PUSH: Received control message: 'PUSH_REPLY,-----------------------------------------------------------------------------------------------------------------------------,redirect-gateway def1,dhcp-option DOMAIN no-ip.biz,dhcp-option DNS 8.9.8.9,topology net30,ping 10,ping-restart 60,redirect-gateway,route +++++++++ 255.255.255.0,ifconfig _________ }}}}}}}}'
2017-06-29 00:33:47 OPTIONS IMPORT: timers and/or timeouts modified
2017-06-29 00:33:47 OPTIONS IMPORT: --ifconfig/up options modified
2017-06-29 00:33:47 OPTIONS IMPORT: route options modified
2017-06-29 00:33:47 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2017-06-29 00:33:47 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:406 ET:0 EL:3 ]
2017-06-29 00:33:47 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2017-06-29 00:33:47 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2017-06-29 00:33:47 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2017-06-29 00:33:47 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2017-06-29 00:33:47 GDG: SIOCGIFHWADDR(lo) failed
2017-06-29 00:33:47 New OpenVPN Status (ADD_ROUTES->LEVEL_CONNECTING_SERVER_REPLIED): ,,,,,
2017-06-29 00:33:47 New OpenVPN Status (ADD_ROUTES->LEVEL_CONNECTING_SERVER_REPLIED): ,,,,,
2017-06-29 00:33:47 ROUTE_GATEWAY 127.100.103.119/255.0.0.0 IFACE=lo
2017-06-29 00:33:47 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
2017-06-29 00:33:47 MANAGEMENT: >STATE:1498685627,ASSIGN_IP,,___________,,,,
2017-06-29 00:33:47 MANAGEMENT: CMD 'needok 'IFCONFIG' ok'
2017-06-29 00:33:47 MANAGEMENT: CMD 'needok 'ROUTE' ok'
2017-06-29 00:33:47 MANAGEMENT: >STATE:1498685627,ADD_ROUTES,,,,,,
2017-06-29 00:33:47 MANAGEMENT: CMD 'needok 'ROUTE' ok'
2017-06-29 00:33:47 MANAGEMENT: CMD 'needok 'ROUTE' ok'
2017-06-29 00:33:47 MANAGEMENT: CMD 'needok 'ROUTE' ok'
2017-06-29 00:33:47 MANAGEMENT: CMD 'needok 'ROUTE' ok'
2017-06-29 00:33:47 MANAGEMENT: CMD 'needok 'ROUTE' ok'
2017-06-29 00:33:47 MANAGEMENT: CMD 'needok 'ROUTE' ok'
2017-06-29 00:33:47 MANAGEMENT: CMD 'needok 'ROUTE' ok'
2017-06-29 00:33:47 MANAGEMENT: CMD 'needok 'DNSSERVER' ok'
2017-06-29 00:33:47 MANAGEMENT: CMD 'needok 'DNSDOMAIN' ok'
2017-06-29 00:33:47 MANAGEMENT: CMD 'needok 'PERSIST_TUN_ACTION' OPEN_BEFORE_CLOSE'
2017-06-29 00:33:47 Opening tun interface:
2017-06-29 00:33:47 Local IPv4: +++++++++/30 IPv6: null MTU: 1500
2017-06-29 00:33:47 DNS Server: 8.9.8.9, Domain: no-ip.biz
2017-06-29 00:33:47 Routes: 0.0.0.0/0, _______________________________________ 
2017-06-29 00:33:47 Routes excluded:  
2017-06-29 00:33:47 VpnService routes installed: 0.0.0.0/0 
2017-06-29 00:33:47 Disallowed VPN apps: 
2017-06-29 00:33:47 New OpenVPN Status (CONNECTED->LEVEL_CONNECTED): SUCCESS,____________,a.b.c.d,wxyz,a.s.d.f,46299
2017-06-29 00:33:47 New OpenVPN Status (CONNECTED->LEVEL_CONNECTED): SUCCESS,____________,a.b.c.d,wxyz,a.s.d.f,,46299
2017-06-29 00:33:47 MANAGEMENT: CMD 'needok 'OPENTUN' ok'
2017-06-29 00:33:47 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2017-06-29 00:33:47 Initialization Sequence Completed
2017-06-29 00:33:47 MANAGEMENT: >STATE:1498685627,CONNECTED,SUCCESS,____________,a.b.c.d,wxyz,a.s.d.f,,46299
2017-06-29 00:33:47 Debug state info: CONNECTED HSPA+ to MOBILE , pause: userPause, shouldbeconnected: true, network: SHOULDBECONNECTED 
I have to stop - too late for me. I'll continue tests tomorrow with a laptop...

Thank you again,
H&M

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests