OpenVPN server easy and fast



I had all of this working as I wanted, till the other day, where I decided to install an mSATA disk in the device.

After installing the mSATA, and making the needed changes to the /etc/config/wireless file, I had my system back online - or so I thought.
It turns out my OpenVPN isn’t accessible from my iPhone any more. Whenever I attempt to connect, I now get connection timeouts. Other VPN connections from the iPhone works as they should.

Any idea how I can debug this?


I see it configured in /etc/config/dhcp and I have running dnsmasq, kresd is not running on my system…


ah, that would be it… Omnia in default configuration using kresd, so we need propably similiar setting for kresd :frowning:


Found the problem: The OpenVPN service wasn’t enabled and thus not running.

But why it has been disabled is a big mystery for me!!!

As I read the thread, @MiSko had a similar problem some days ago, so this might be something for the devs to look into?


It is because it is not starting on boot.
Easily solved to toggeling it to enabled in LuCI under System >>> Startup.


Out of curiosity I’ve tried to configure kresd (by following Dnsmasq .lan domain while still using knot resolver post)…

What worked for me under OpenVPN was to change IP address from to, so now I have following in /etc/config/openvpn:

	list push 'dhcp-option DNS'

Output from dig command helped a lot with debugging as with IP the result was:

$ dig @ -t ANY omnia.lan
;; reply from unexpected source:, expected


Thanks @iddqd, this was exactly what I did (and attempted to write above).

The mystery remains, though - why did it suddenly change to not start on boot?

After setting up OpenVPN, I did reboot least 15 times, and each time the VPN setup remained working.
The only difference I can think of this time, is that I powered down the device completely to install the mSATA.
So perhaps we have some settings that somehow survives a reboot?


I didnt configure dnsmasq at all (and still, my .lan works). I tried the dig on my LAN subnet IP (which actually doesnt works as pushed DNS via OpenVPN), and from omnia I have different result (it doesnt point me to any other IP):

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 39446
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1


Well, it kind of works for me, but only for couple of seconds (about 15). I used installation trough Foris. I extracted certs and keys from downloaded configuration file and created VPN configuration manually trough GUI in Ubuntu. Then, I was able to connect and ping my NAS at But after few seconds it stopped working. I disconnected from VPN and connect again. It started working but after another couple of seconds it failed again. I have no idea why is this happening.

> openvpn --version
OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec  1 2014

> uname -a
Linux Cejhon-NTB 3.13.0-96-generic #143-Ubuntu SMP Mon Aug 29 20:15:20 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

> ifconfig
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
      inet addr:  P-t-P:  Mask:
      RX packets:36 errors:0 dropped:0 overruns:0 frame:0
      TX packets:52 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:100 
      RX bytes:4004 (4.0 KB)  TX bytes:5454 (5.4 KB)

wlan0     Link encap:Ethernet  HWaddr dc:a9:71:19:82:b4  
      inet addr:  Bcast:  Mask:
      inet6 addr: fe80::dea9:71ff:fe19:82b4/64 Scope:Link
      RX packets:72595 errors:0 dropped:0 overruns:0 frame:0
      TX packets:63814 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:63975155 (63.9 MB)  TX bytes:12927280 (12.9 MB)

Lokální síť mám a při generování configurace VPN jsem nastavil To je předpokládám správně, když se mi to alespoň na chvíli připojí.

Připojení na mobilu mi ale drží.


thanks man for the settings. Unfortunately I won’t be able to test it out any sooner than at the weekend.

Other features that would be nice to have :slight_smile: :

  1. generate client_file .ovpn instead of client_file .conf by default (Becase of Windows importing process)
  2. Run the openvpn server as unprivileged user (e.g. nobody:nogroup)
  3. generate and secure the communication with tls-auth ta.key by default


That’s indeed weird and it should not happen. Is there something useful in the logs?
Anyways, if you want to make it bulletproof you could write a small script to check if OVPN is running and if necessary to start it.


Device Turris Omnia - RTROM01
Turris OS version 3.6.1
Kernel version 4.4.51-627f0117679bc72ef5e58881035f567a-3

After failing to generate CA: I uninstalled openvpn through updater, removed files from /etc/ssl/ca/openvpn/, rebooted turris, reinstalled openvpn, selected “Generate CA” and can get no further. The openvpn page in foris shows the certs generating then returns to “Currently there is no OpenVPN certificate authority(CA).”

/etc/ssl/ca/openvpn/ shows 15 files with time stamp after reboot:
-rw-r–r-- 1 root root 6704 Mar 27 05:30 01.crt
-rw-r–r-- 1 root root 1582 Mar 27 05:30 01.csr
-r-------- 1 root root 3276 Mar 27 05:30 01.key
-rw-r–r-- 1 root root 6704 Mar 27 05:30 01.pem
-rw-r–r-- 1 root root 893 Mar 27 05:30 ca.crl
-rw-r–r-- 1 root root 1862 Mar 27 05:29 ca.crt
-r-------- 1 root root 3272 Mar 27 05:29 ca.key
-rw-r–r-- 1 root root 3 Mar 27 05:30 crlnumber
-rw-r–r-- 1 root root 3 Mar 27 05:29 crlnumber.old
-rw-r–r-- 1 root root 39 Mar 27 05:30 index.txt
-rw-r–r-- 1 root root 20 Mar 27 05:30 index.txt.attr
-rw-r–r-- 1 root root 0 Mar 27 05:29 index.txt.old
-rw-r–r-- 1 root root 17 Mar 27 05:29 notes.txt
-rw-r–r-- 1 root root 3 Mar 27 05:30 serial
-rw-r–r-- 1 root root 3 Mar 27 05:29 serial.old

Why is openvpn page indicating no OpenVPN certificate authority?


The files seems alright. Could you try to run following script:


socat STDIO EXEC:'/usr/bin/nuci -e trace -s disable',pty <<ENDXML
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
]]>]]><?xml version="1.0" encoding="UTF-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<filter type='subtree'><cas xmlns=''>


I ran your script approximately 2 hours after your message here on the forum. Thank you very much for the help. The router has been perfect so far so thanks to the team, too.


I like the feature to issue certificates and configuration files for clients. And the ability to revoke them.
I created the configuration in Foris, modified in Luci.
Everything is working like I need.

If I go to Foris, the configuration files are hidden, I need to reapply the VPN to issue a new certificate.

That reset the Luci OpenVPN setting.

Is there a work around?

Which script can I run to crate .conf files and revoke access?


I just changed the configuration file and restart the OpenVPN Server and have no problem to issue new certificates with forris.

What did you change in Luci?

I changed for example the cypher and am still able to fully use forris.


I added some routes.
I don’t think it is Luci problem now.
Everytime I access Foris it prompt me ot apply the changes, even if they are already there and it is running fine.



I noticed that after each power outage I have to “Apply configuration” for OpenVPN in Foris before OpenVPN starts to work again. Is this expected? I hoped that once enabled and configured, it will automatically start even after router reboot. I never tried to set up OpenVPN manually on turris and I only used the Foris interface for OpenVPN configuration, so I don’t expect anything to be messed up in my OpenVPN configuration.

Did anyone else have the same problem? If not I guess I will have to report an issue.



I had to re-apply.
I noticed that I had duplicate​ firewall entries for the VPN.
When I checked them in Luci and click save, they will be ok, but Doris VPN would need to reapplied.
A reboot may validate the firewall rules and remove the wrong one.


Hi, I noticed higher battery drain on Android client with default Turris VPN configuration. It is OpenVPN feature. The fix is easy - change “keepalive 10 120” to “keepalive 1800 3600” in you /etc/config/openvpn

Is it possible to make this change in default OpenVPN Turris generator?