Openvpn shell vs openvpn luci instance

Installing and Using OpenWrt Network and Wireless Configuration
1

Dear all,
I've a curious (at least for me) situation.

I run an internal vpn server on a zeroshell machine.
I've copied cert, key, CA and VPN.ovpn files under /etc/openvpn. If I run
openvpn VPN.ovpn

openwrt connects with no issue to the server

On the other end, if I try to use the luci instance in order to link it to a interface and a firewall zone, openwrt doesn't connect.

in /etc/config/openvpn file I have:

config openvpn 'vpn_zs'
        option config '/etc/openvpn/zeroshell.conf'
        option enable '1'

which I've assumed to work as everything is fine in the config file

I'm now working on coding the .ovpn inside the /etc/config/openvpn but I found quit singular that one way works but not the other.

Any help?

Cheers

2

OpenVPN will automatically attempt to load any file named *.conf within /etc/openvpn. This is often not what you want-- thus the convention of naming configuration files .ovpn instead.

In OpenWrt I usually put VPN related files like certificates under /etc/config, for example make a directory /etc/config/vpnfiles/. These files will be saved during a system upgrade.

3

ciao mk24,

thanks for your valuable hint regarding the storing of the files. this will reduce headache in the future!!

after 'translating' the .ovpn file into luci code this is the error I read in the system log:

Fri Dec 27 19:23:19 2019 daemon.err openvpn(vpn_zs)[10174]: Certificate does not have key usage extension
Fri Dec 27 19:23:19 2019 daemon.notice openvpn(vpn_zs)[10174]: VERIFY KU ERROR
Fri Dec 27 19:23:19 2019 daemon.err openvpn(vpn_zs)[10174]: OpenSSL: error:14090086:lib(20):func(144):reason(134)
Fri Dec 27 19:23:19 2019 daemon.err openvpn(vpn_zs)[10174]: TLS_ERROR: BIO read tls_read_plaintext error
Fri Dec 27 19:23:19 2019 daemon.err openvpn(vpn_zs)[10174]: TLS Error: TLS object -> incoming plaintext read error
Fri Dec 27 19:23:19 2019 daemon.err openvpn(vpn_zs)[10174]: TLS Error: TLS handshake failed
Fri Dec 27 19:23:19 2019 daemon.err openvpn(vpn_zs)[10174]: Fatal TLS error (check_tls_errors_co), restarting
Fri Dec 27 19:23:19 2019 daemon.notice openvpn(vpn_zs)[10174]: SIGUSR1[soft,tls-error] received, process restarting
Fri Dec 27 19:23:19 2019 daemon.notice openvpn(vpn_zs)[10174]: Restart pause, 5 second(s)

the vpn authentication is with user&pwd, certs and pwd on key.

this is the vpn_zs part of openvpn config file:

config openvpn 'vpn_zs'
        list remote '10.10.10.5'
        option port '1194'
        option dev 'tap'
        option proto 'tcp-client'
        option auth_user_pass '/etc/config/vpn/auth.txt'
        option ca '/etc/config/vpn/CA.pem'
        option cert '/etc/config/vpn/openwrt_cert.pem'
        option key '/etc/config/vpn/openwrt_key.pem'
        option askpass '/etc/config/vpn/pwd.txt'
        option compress 'lzo'
        option verb '3'
        option mute '20'
        option resolv_retry 'infinite'
        option nobind '1'
        option client '1'
        option enabled '1'
        option route_noexec '1'
        option persist_tun '1'
        option persist_key '1'
        option redirect_gateway 'local def1'
        option auth_nocache '1'
        option remote_cert_tls 'server'

whilst the .ovpn file is:

remote 10.10.10.5 1194
proto tcp
auth-user-pass /etc/config/vpn/auth.txt
ca /etc/config/vpn/CA.pem
cert /etc/config/vpn/openwrt_cert.pem
key  /etc/config/vpn/openwrt_key.pem
comp-lzo
verb 3
mute 20
resolv-retry infinite
nobind
client
dev tap
persist-key
persist-tun
--pull-filter ignore redirect-gateway
askpass /etc/config/vpn/pwd.txt

above all I'm not sure about the --pull-filter translation..

Do you have further suggestion about TLS errors?

Do you know why the

option config '/etc/config/vpn/zeroshell.ovpn'

doesn't work at all as when invoked by the shell with openvpn?

thanks again

4

In my experience there was another issue since upgrade some months ago.

But you should remove the option.

5

Yes that means you are requiring stricter security that the server's certificate must have the "https web server" usage flag set. Or your client will refuse to connect. (Also, a strictly configured server will reject your client certificate if it doesn't have web client set.)

If you control the server, you should give it a new certificate that is so configured. If you don't, you'll have to remove that option from the client config.