The upgrades are repeatedly destroying my custom openvpn

Last time, around one month ago, the OS was upgraded automatically, my customized vpn stopped working.
Comparing old and new configurations (thank to schnapps) I realized that the diffie-helman parameters path was changed. I calmed down and changed the configuration file accordingly and the world has been saved.

But this time (day or couple of ago) the OS upgrade broke my vpn again.
Now I’m unable to fix it anyhow.

This is my config that was perfectly working before the upgrade:

/etc/openvpn/my-vpn.conf

client-to-client
persist-key
persist-tun
ca /etc/ssl/ca/openvpn/ca.crt
cert /etc/ssl/ca/openvpn/01.crt
crl-verify /etc/ssl/ca/openvpn/ca.crl
dev tun_turris
dh /etc/ssl/ca/openvpn/dhparam.pem
ifconfig-pool-persist /tmp/ipp.txt
keepalive 10 120
key /etc/ssl/ca/openvpn/01.key
mute 20
port 1194
proto udp
push “route 192.168.1.0 255.255.255.0”
server 10.111.111.0 255.255.255.0
status /tmp/openvpn-status.log
verb 3
client-config-dir ccd
route 192.168.2.0 255.255.255.0

There are client custom data in short files in
/etc/openvpn/ccd/

/mnt/snapshot-@54/etc/config/openvpn

config openvpn ‘custom_config’
option enabled ‘1’
option config ‘/etc/openvpn/my-vpn.conf’

config openvpn ‘server_turris’
option enabled ‘0’
option port ‘1194’
option proto ‘udp’
option dev ‘tun_turris’
option ca ‘/etc/ssl/ca/openvpn/ca.crt’
option crl_verify ‘/etc/ssl/ca/openvpn/ca.crl’
option cert ‘/etc/ssl/ca/openvpn/01.crt’
option key ‘/etc/ssl/ca/openvpn/01.key’
option server ‘10.111.111.0 255.255.255.0’
option ifconfig_pool_persist ‘/tmp/ipp.txt’
option duplicate_cn ‘0’
option keepalive ‘10 120’
option persist_key ‘1’
option persist_tun ‘1’
option status ‘/tmp/openvpn-status.log’
option verb ‘3’
option mute ‘20’
option dh ‘/etc/ssl/ca/openvpn/dhparam.pem’
option enabled ‘1’
list push ‘route 192.168.1.0 255.255.255.0’

root@turris:~#

Yes, there was “a bug” with two contradicting "option enabled ‘0’ and ‘1’ and I didn’t know it, but it worked.
Now this doesn’t work with any of the values nor with both of them.

If the opevpn server enable switch in Reforis isn’t activated, the /var/etc/openvpn-server_turris.conf isn’t generated, but if it’s enabled, the custom options from /etc/openvpn/my-vpn.conf’ are ignored.

I am sad, angry and tired of it.
I don’t know what should I do to make it work again and make it working permanently.

Please do something about it!!!
There is no need you to analyze my vpn configuration, just improve the way the system behaves when custom configuration is needed.
(BTW: I still want to use the built in keys management, because it’s great)

Thank you

Please could anyone reply to my question?

I still haven’t figured out what to do, and my network is still split to two pieces.

What’s the prefered way to launch openvpn with non-default configuration (the one, that I can prepare via the web interface).

Now I am continuously logged in as root via ssh (ten days!!!) and I’m running the openvpn binary from the shell. That’s really unsafe and very silly. I don’t know what to do instead of it.

On my gentoo box there is /etc/init.d/local init script that is launching my services that are not managed by the distribution, but i don’t know how something like that one can do in turris os.

Please provide one single way I can do it, which will not break after a next update. Or at least a way I can make it work until the update.

Thank you

While I have no input on your real problem, I have input onimproving your work-around.

Install screen opkg upgrade; opkg install screen .
Then you can log in via ssh, and start or reattach to screen screen -RR, start your binary, and type ctrl-a d to leave screen with that session still running, yoy then can logout with your binary running.

Thanks. I know the screen utility. I will switch to that at least. It’s definitely better option than be continuously logged in, but that will also die on reboot or power loss :frowning:

I hope that somebody from official TOS support will answer and recommend me some more permanent solution.

That is what I’ve been afraid of:
root@turris:~# opkg install screen
Unknown package ‘screen’.
Collected errors:

  • opkg_install_cmd: Cannot install package screen.

Years ago when i wanted to install some general package to my TO, I have had to build it myself.
Now I haven’t enough time to set the toolchain up again.

My bad it should have been opkg update to load the current package list from the servers, upgrade was clearly wrong (I was writing from memory instead of actually looking at my computer)

root@turris:~# opkg update
Downloading https://repo.turris.cz/hbs/omnia/packages/core/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_core
Downloading https://repo.turris.cz/hbs/omnia/packages/core/Packages.sig
Signature check passed.
Downloading https://repo.turris.cz/hbs/omnia/packages/base/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_base
Downloading https://repo.turris.cz/hbs/omnia/packages/base/Packages.sig
Signature check passed.
Downloading https://repo.turris.cz/hbs/omnia/packages/cesnet/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_cesnet
Downloading https://repo.turris.cz/hbs/omnia/packages/cesnet/Packages.sig
Signature check passed.
Downloading https://repo.turris.cz/hbs/omnia/packages/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_luci
Downloading https://repo.turris.cz/hbs/omnia/packages/luci/Packages.sig
Signature check passed.
Downloading https://repo.turris.cz/hbs/omnia/packages/node/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_node
Downloading https://repo.turris.cz/hbs/omnia/packages/node/Packages.sig
Signature check passed.
Downloading https://repo.turris.cz/hbs/omnia/packages/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_packages
Downloading https://repo.turris.cz/hbs/omnia/packages/packages/Packages.sig
Signature check passed.
Downloading https://repo.turris.cz/hbs/omnia/packages/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_routing
Downloading https://repo.turris.cz/hbs/omnia/packages/routing/Packages.sig
Signature check passed.
Downloading https://repo.turris.cz/hbs/omnia/packages/sidn/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_sidn
Downloading https://repo.turris.cz/hbs/omnia/packages/sidn/Packages.sig
Signature check passed.
Downloading https://repo.turris.cz/hbs/omnia/packages/telephony/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_telephony
Downloading https://repo.turris.cz/hbs/omnia/packages/telephony/Packages.sig
Signature check passed.
Downloading https://repo.turris.cz/hbs/omnia/packages/turrispackages/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_turrispackages
Downloading https://repo.turris.cz/hbs/omnia/packages/turrispackages/Packages.sig
Signature check passed.
root@turris:~# opkg install screen
Installing screen (4.8.0-2) to root...
Downloading https://repo.turris.cz/hbs/omnia/packages/packages/screen_4.8.0-2_arm_cortex-a9_vfpv3-d16.ipk
Configuring screen.

The installed screen then works for me.

1 Like

Oh, thanks. I didn’t know this does the trick.
Now the openvpn is running in the screen session.

1 Like

An OS update has been announced by my Omnia and after the reboot, with renewed normal configuration of the openvpn (gui configuration disabled, custom configuration enabled) the vpn is working well again!!!

Thanks to all involved persons

J.

Mark as solved and close the topic.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.