Can't get openvpn to work since 5.0.3

Software SW help
1

Since I updated to 5.0.3 openvpn doesn’t seem to be sending packets correctly.

It connects, but I can’t get to any of my internal hosts. I suspect it’s a routing issue. Looking at ip route, I don’t even see the tun_turris interface:

ip route
default via <outside subnet>.97 dev eth2  src <outside subnet>.107
<outside subnet>.96/27 dev eth2 scope link  src <outside subnet>.107
84.05.53.14 via <outside subnet>.97 dev eth2
192.168.40.0/24 dev br-lan scope link  src 192.168.40.1
192.168.130.0/24 dev br-IOT scope link  src 192.168.130.1

The logs from the client and the server seem to indicate that the connection proceeded normally, but even on the Omnia, I can’t ping the client IP.

Looking at the “Firewall Status” page in LuCI, I don’t even see any packets for the tun_turris interface.

I’m not sure what to look for or where to go. I’m fairly sure it worked in 5.0.2, but I’m certain it worked when I first upgraded to 5.0.0

There’s so much to look at here, I didn’t really want to spam the forum with logs that aren’t relevant. I’m also concerned I missed a bug/note that indicated it was broken.

2

I would check /etc/config/firewall if you have zone and forwarding rules setup for vpn_turris(resp: tun_turris). There you should have also “allow-ping/allow-igmp” rules (if you want ping to go thru)
Additionally check /etc/config/network if you have zone for vpn defined correctly. I belive that Foris is responsible for adding rules to firewall. So maybe just disable/enable openvpn with save+apply in Foris should do it for you. (do the backup of uci config for openvpn and later you can compare them).

Also i would check for https://community.openvpn.net/openvpn/wiki/DeprecatedOptions if there was some update for openvpn package it might be the case. (i had some issues some time ago with comp-lzo vs compress directives, causing similar situation (tunel seems up, but is not, no packets passing thru). Actual config used by OpenVPN is located at /var/etc/openvpn-server_turris.conf, which is generated from /etc/config/openvpn. Do you have “push” directives there ?

After update sometimes there is backup of changed configs, so also check if you do not have /etc/config/openvpn-opkg (or firewal-opkgl, network-opkg ones as well) present.

If you think your update went wrong,

you can return back to some working snapshot using https://docs.turris.cz/geek/schnapps/schnapps/ and postpone the update (or do it manually to see the output in console). You see updater sometimes has issues with resolving the remote servers and fails, sometimes updater had issues during post-install steps , sometimes process just hangs and you even do not have “post-install” schnapps snapshot created (if that is your case; and you have only pre-install one, just rollback …, it will cost you many hours to fix it…)

3

I think I’ve found the issue. I’m not sure how to get around it.

I do have a route pushed:

list push 'route 192.168.40.0 255.255.255.0'

And in the logs I found this when I tried to connect one of my vpn connections (I guess I didn’t look hard enough at the logs, sorry).

openvpn(server_turris)[20371]: /sbin/route del -net 10.255.111.0 netmask 255.255.255.0
openvpn(server_turris)[20371]: ERROR: Linux route delete command failed:external program exited with error status: 1 
openvpn(server_turris)[20371]: Closing TUN/TAP interface
openvpn(server_turris)[20371]: /sbin/ifconfig tun_turris 0.0.0.0
openvpn(server_turris)[20371]: SIGTERM[hard,] received, process exiting

This seems to happen after a short time, less than a minute. If I connect a client to the VPN, I can ping for a bit until the /sbin/route del ... command.

Additionally after I stopped and started /etc/init.d/openvpn, the route showed up again.

4

Try to look also into client’s log eventually increase logging verbosity from 3 to 5 (on client or on server). Posted log output is so short, there should be much more before that block you posted. In debug log you should see validation of client config vs server. If there are some missing directives/options/values in server/client config, openvpn might decide to use default ones. If there is situation where client has something defined, but server not, you might end up with missmatching setup (for example touching cipher options can lead to various issues during handshake step).Which might cause some issues. Debug log usually recommend what to change.(but it is looong reading).

Also check that you do not have “user nobody” or/and “group nobody” directive in client config. Aside , when testing vpn tunnel from same local network, you will need to add “float” to client config,otherwise route-add/del might not work properly or at all.

without config or/and log dump i can’t help more…:slight_smile:

5

As I mentioned above, I didn’t really want to spam the forum with logs unless necessary. I’ll go ahead and post them.

/etc/config/openvpn:

config openvpn 'server_turris'
        option enabled '1'
        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 dh '/etc/dhparam/dh-default.pem'
        option server '10.255.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'
        list push 'route 192.168.40.0 255.255.255.0'
        option script_security '2'
        option client_connect '/etc/openvpn/up.sh'    
        option client_disconnect '/etc/openvpn/down.sh'
        option compress ''

Here’s the logs from starting openvpn and having it stop from a client connecting and automatically restart:

Jul 13 21:26:43 openvpn(server_turris)[20371]: OpenVPN 2.4.7 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Jul 13 21:26:43 openvpn(server_turris)[20371]: library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10
Jul 13 21:26:43 openvpn(server_turris)[20371]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 13 21:26:43 openvpn(server_turris)[20371]: Diffie-Hellman initialized with 2048 bit key
Jul 13 21:26:43 openvpn(server_turris)[20371]: TUN/TAP device tun_turris opened
Jul 13 21:26:43 openvpn(server_turris)[20371]: TUN/TAP TX queue length set to 100
Jul 13 21:26:43 openvpn(server_turris)[20371]: /sbin/ifconfig tun_turris 10.255.111.1 pointopoint 10.255.111.2 mtu 1500
Jul 13 21:26:43 openvpn(server_turris)[20371]: /sbin/route add -net 10.255.111.0 netmask 255.255.255.0 gw 10.255.111.2
Jul 13 21:26:43 openvpn(server_turris)[20371]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Jul 13 21:26:43 openvpn(server_turris)[20371]: Socket Buffers: R=[163840->163840] S=[163840->163840]
Jul 13 21:26:43 openvpn(server_turris)[20371]: UDPv4 link local (bound): [AF_INET][undef]:1194
Jul 13 21:26:43 openvpn(server_turris)[20371]: UDPv4 link remote: [AF_UNSPEC]
Jul 13 21:26:43 openvpn(server_turris)[20371]: MULTI: multi_init called, r=256 v=256
Jul 13 21:26:43 openvpn(server_turris)[20371]: IFCONFIG POOL: base=10.255.111.4 size=62, ipv6=0
Jul 13 21:26:43 openvpn(server_turris)[20371]: ifconfig_pool_read(), in='momhelp,10.255.111.4', TODO: IPv6
Jul 13 21:26:43 openvpn(server_turris)[20371]: succeeded -> ifconfig_pool_set()
Jul 13 21:26:43 openvpn(server_turris)[20371]: ifconfig_pool_read(), in='phonetest,10.255.111.8', TODO: IPv6
Jul 13 21:26:43 openvpn(server_turris)[20371]: succeeded -> ifconfig_pool_set()
Jul 13 21:26:43 openvpn(server_turris)[20371]: IFCONFIG POOL LIST
Jul 13 21:26:43 openvpn(server_turris)[20371]: momhelp,10.255.111.4
Jul 13 21:26:43 openvpn(server_turris)[20371]: phonetest,10.255.111.8
Jul 13 21:26:43 openvpn(server_turris)[20371]: Initialization Sequence Completed
Jul 13 21:26:43 netifd: Interface 'vpn_turris' is enabled
Jul 13 21:26:43 netifd: Interface 'vpn_turris' is disabled
Jul 13 21:26:43 netifd: Interface 'vpn_turris' is enabled
Jul 13 21:26:43 netifd: Network device 'tun_turris' link is up
Jul 13 21:26:43 netifd: Interface 'vpn_turris' has link connectivity 
Jul 13 21:26:43 netifd: Interface 'vpn_turris' is setting up now
Jul 13 21:26:43 netifd: Interface 'vpn_turris' is now up
Jul 13 21:26:45 firewall: Reloading firewall due to ifup of vpn_turris (tun_turris)
Jul 13 21:28:47 openvpn(server_turris)[20371]: 199.3.14.243:7627 TLS: Initial packet from [AF_INET]199.3.14.243:7627, sid=e17ea85c 64168da6
Jul 13 21:28:51 openvpn(server_turris)[20371]: 199.3.14.243:7627 VERIFY OK: depth=1, CN=openvpn
Jul 13 21:28:51 openvpn(server_turris)[20371]: 199.3.14.243:7627 VERIFY OK: depth=0, CN=phonetest
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 peer info: IV_VER=2.5_master
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 peer info: IV_PLAT=android
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 peer info: IV_PROTO=2
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 peer info: IV_NCP=2
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 peer info: IV_LZ4=1
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 peer info: IV_LZ4v2=1
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 peer info: IV_LZO=1
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 peer info: IV_COMP_STUB=1
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 peer info: IV_COMP_STUBv2=1
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 peer info: IV_TCPNL=1
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 peer info: IV_GUI_VER=de.blinkt.openvpn_0.7.15
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 peer info: IV_SSO=openurl,crtext
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 4096 bit RSA
Jul 13 21:28:53 openvpn(server_turris)[20371]: 199.3.14.243:7627 [phonetest] Peer Connection Initiated with [AF_INET]199.3.14.243:7627
Jul 13 21:28:53 openvpn(server_turris)[20371]: phonetest/199.3.14.243:7627 MULTI_sva: pool returned IPv4=10.255.111.10, IPv6=(Not enabled)
Jul 13 21:28:53 openvpn(server_turris)[20371]: phonetest/199.3.14.243:7627 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_607defb103dfb366.tmp
Jul 13 21:28:53 openvpn(server_turris)[20371]: phonetest/199.3.14.243:7627 MULTI: Learn: 10.255.111.10 -> phonetest/199.3.14.243:7627
Jul 13 21:28:53 openvpn(server_turris)[20371]: phonetest/199.3.14.243:7627 MULTI: primary virtual IP for phonetest/199.3.14.243:7627: 10.255.111.10
Jul 13 21:28:54 openvpn(server_turris)[20371]: event_wait : Interrupted system call (code=4)
Jul 13 21:28:54 openvpn(server_turris)[20371]: /sbin/route del -net 10.255.111.0 netmask 255.255.255.0
Jul 13 21:28:54 openvpn(server_turris)[20371]: ERROR: Linux route delete command failed: external program exited with error status: 1
Jul 13 21:28:54 openvpn(server_turris)[20371]: Closing TUN/TAP interface
Jul 13 21:28:54 openvpn(server_turris)[20371]: /sbin/ifconfig tun_turris 0.0.0.0
Jul 13 21:28:54 netifd: Network device 'tun_turris' link is down
Jul 13 21:28:54 netifd: Interface 'vpn_turris' has link connectivity loss
Jul 13 21:28:54 netifd: Interface 'vpn_turris' is now down
Jul 13 21:28:54 openvpn(server_turris)[20371]: SIGTERM[hard,] received, process exiting

After more thorough inspection of my logs, a client connecting isn’t required for this behavior. Between midnight UTC and 12:17 UTC, it’s restarted 222 times and no one has been connecting. It’s not consistent either. Between 00:10:45 and 00:12:00 it restarted 30 times, mostly every 2-3 seconds it seems. Other times, there are gaps up to 15 minutes between restarts.

I can up the log verbosity and see if anything jumps out.

Here’s the client config:

##############################################
# Openvpn client configuration generated by  #
# router Turris based on Sample client-side  #
# OpenVPN 2.0 config file                    #
#                                            #
# This configuration can be used only on     #
# a single client.                           #
#                                            #
#                                            #
# On Windows, you might want to rename this  #
# file so it has a .ovpn extension           #
##############################################

client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
dev tun_turris

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one.  On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap

proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
;remote my-server-1 1194
;remote my-server-2 1194
remote 164.23.24.17 1194

# Choose a random host from the remote
# list for load-balancing.  Otherwise
# try hosts in the order specified.
;remote-random

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
;user nobody
;group nobody
# Try to preserve some state across restarts.
persist-key
persist-tun

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
mute-replay-warnings

<ca>

</ca>
<cert>

</cert>
<key>

</key>

remote-cert-tls server


# Set log file verbosity.
verb 3

# Silence repeating messages
;mute 20

# To enable to process DNS push request from the server on linux machines (non systemd-resolved)
# note that you might need to have resolvconf program installed
;script-security 2
;up /etc/openvpn/update-resolv-conf
;down /etc/openvpn/update-resolv-conf

# To enable to process DNS push request from the server on linux machines (systemd-resolved)
# see https://github.com/jonathanio/update-systemd-resolved
;script-security 2
;setenv PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
;up /etc/openvpn/update-systemd-resolved
;down /etc/openvpn/update-systemd-resolved
;down-pre

But I don’t think the client connecting is the issue any more.

6

Can you post your routes with openvpn running and stopped?

Does this happen after restarting whole system? If routes are somehow messed up, restarting and setting network again on boot could fix it.
And to be sure, please save logs or screenshots of state before and after restart, so we can compare it later.

7

Running:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         <outside subnet>.97   0.0.0.0         UG    0      0        0 eth2
10.255.111.0    10.255.111.2    255.255.255.0   UG    0      0        0 tun_turris
10.255.111.2    0.0.0.0         255.255.255.255 UH    0      0        0 tun_turris
<outside subnet>.96   0.0.0.0         255.255.255.224 U     0      0        0 eth2
<he gateway>  <outside subnet>.97   255.255.255.255 UGH   0      0        0 eth2
192.168.40.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
192.168.130.0   0.0.0.0         255.255.255.0   U     0      0        0 br-IOT

Stopped:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         <outside subnet>.97   0.0.0.0         UG    0      0        0 eth2
<outside subnet>.96   0.0.0.0         255.255.255.224 U     0      0        0 eth2
<he gateway>  <outside subnet>.97   255.255.255.255 UGH   0      0        0 eth2
192.168.40.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
192.168.130.0   0.0.0.0         255.255.255.0   U     0      0        0 br-IOT

I think the first post, openvpn had stopped running when I tried getting a route table. Curiously route and route -n have different entries.

route has
10.255.111.2 * 255.255.255.255 UH 0 0 0 tun_turris

where route -n has
10.255.111.0 10.255.111.2 255.255.255.0 UG 0 0 0 tun_turris
10.255.111.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun_turris

[edit] After checking a second time, (and third and fourth), both route and route -n show the same information.

Openvpn seems to behave better if it’s been restarted by the init script rather than just having it restart in a loop. I’m not sure if it’s related, but this morning my network throughput to the internet was very slow until I restarted the router.

I’ve had openvpn off since then. I’ll keep it running for now to see if there’s any correlation.

8

I have an update on this for this morning.

I left the openvpn server running overnight and this morning found that the routes had gone for the tun_turris interface. However, the connection doesn’t reset constantly after I’ve connected. If I attempt to add the route by hand, I get

route: SIOCADDRT: Network unreachable

Which seems odd since the ip link and ip addr show the tun_turris device and I can ping the local address.

When I stopped openvpn and restarted it, then connected my client, now the openvpn seems to be restarting in a loop, dying and restarting as fast as it can.

I think it’s time I opened a bug report on the github.

I saw some additional, somewhat concerning items that I don’t think are related. Looking at the logs I saw some odd entries for IPs I didn’t recognize:

Jul 14 21:24:00 openvpn(server_turris)[15305]: MULTI: multi_create_instance called
Jul 14 21:24:00 openvpn(server_turris)[15305]: 185.200.118.70:39961 Re-using SSL/TLS context
Jul 14 21:24:00 openvpn(server_turris)[15305]: 185.200.118.70:39961 Control Channel MTU parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ] 
Jul 14 21:24:00 openvpn(server_turris)[15305]: 185.200.118.70:39961 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ] 
Jul 14 21:24:00 openvpn(server_turris)[15305]: 185.200.118.70:39961 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Jul 14 21:24:00 openvpn(server_turris)[15305]: 185.200.118.70:39961 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Jul 14 21:24:00 openvpn(server_turris)[15305]: 185.200.118.70:39961 TLS: Initial packet from [AF_INET]185.200.118.70:39961, sid=12121212 12121212
Jul 14 21:25:00 openvpn(server_turris)[15305]: 185.200.118.70:39961 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jul 14 21:25:00 openvpn(server_turris)[15305]: 185.200.118.70:39961 TLS Error: TLS handshake failed
Jul 14 21:25:00 openvpn(server_turris)[15305]: 185.200.118.70:39961 SIGUSR1[soft,tls-error] received, client-instance restarting

I’m assuming this is someone attempting to break into my system. There are several sequences like this, all from different IPs.

9

Final reply from my end. There was a bug report opened on this a few days ago on the Gitlab.

I will continue to watch and follow up there.

10

ad_log: i think you have issue with MTU value link-mtu=1541 dev-mtu=1500 , TOS usually have mtu=1500 as default on outbound link …
so look around the config if you set it or not. You can set link-mtu (for openvpn) 1400-1450 for debug purpose (normally you don’t need to fidle with mtu at all), to see what is really wrong (i had similar issue like this just because i’ve changed values for options “cihper” or “mtufix” or “fragment” causing somehow that mtu was over 1500 …)

that is pretty normal ; yes you are right … :), but it is(it should be) harmless.

11

I’ve not set it in the openvpn config and I only found one other reference to mtu in my /etc/config directory and that was in networking for my IPv6 tunnel.

It looks like I should try something like in the openvpn config section for the server?

    option link_mtu '1420'

or

    option tun_mtu '1420'

I tried one, then the other. In both cases, openvpn continued to crash/restart loop.

Thanks anyway. I’ll wait for a bug fix, or recommendation from the Turris folks on Gitlab.

12

While waiting for bugfix , maybe this might still help …

if lowering mtu does not make the openvpn to move at least few steps further tunnel establish, you can revert it. In normal situation you don’t need to set mtu(dev/link) anywhere.

From my previous "testing"

(before foris introduced easy-openvpn plugin) i faced higher mtu situation several times. When i edited uci config manually many times → having explicit cipher list(and own list), when i somehow mixed client/server directives, or had faulty combinaitons.
if you used Luci to edit openvp (and also advanced options) , it might be the case that some of the client/server directives mixed together… )

If you have more openvpn server instances, i would try to keep just one up. (btw: why you have more ? (udp/tcp variant ?)

that is telling client to choose compression, if not specified (i do not see compress or comp-lzo there), it might get confused (or it might be actually reason for mtu over 1500)
note small difference :slight_smile: “-” vs “_” → comp_lzo(openwrt uci style) vs comp-lzo(openvpn style)

for more info : https://community.openvpn.net/openvpn/ticket/952
or compress/comp-lzo section : https://community.openvpn.net/openvpn/wiki/DeprecatedOptions

I have comp_lzo 'yes' on server side (in future releases i will be forced to change it to “compress” ) and compress lzo on client side.

Here is part from openvpn ref.manual , pretty handy (i will bookmark it for myself :slight_smile: bold ones caused me some issues while trying to connect

Clients that connect with options that are incompatible with those of the server will be disconnected.Options that will be compared for compatibility include dev-type, link-mtu, tun-mtu, proto, tun-ipv6, ifconfig, comp-lzo, fragment, keydir, cipher, auth, keysize, secret, no-replay, no-iv, tls-auth, key-method, tls-server, and tls-client.

I have clients having 2.2.x, 2.3.x or2.4.x versions so i might not have it in ideal setup. But so far no more complains. I’ve checked with each user what needs to be changed.
I am actually thinking to disable compression completely :slight_smile: , but i will wait for 2.5.x server version.

maybe it is not important but i’ve noticed that now i have option proto 'udp4' in client/server configs.

ad_scripts: i would disable options for scripts (up.sh/down.sh) during the testing/debugging and lower script_security to 1 (or disable it , default will be considered).

cheers and good luck :slight_smile:

13

Thanks. I’ll try those things.

As for compression, it wasn’t clear how to turn it off as I was under the impression (perhaps faulty) that compression was not secure in some way.

From: https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/

If the algorithm parameter is empty, compression will be turned off, but the packet framing for compression will still be enabled, allowing a different setting to be pushed later.

I’ll make some adjustments in the server settings and see if anything different happens. Though almost all of my issues have been happening without any clients connecting.

1 Like
14

I appreciate the tremendous amount of work the Turris folks put into developing the easy openvpn setup and how much work we customers put into setting up our clients to use it. Having acknowledged that, everyone on earth should abandon openvpn and switch to wireguard.

Since wireguard runs in kernel space, rather than user space like openvpn, it is MUCH faster. It is also much simpler to configure. There are LUCI packages to help you set it up. It is a learning curve but well worth.

15

well, i tried your wireguard, but to say that it is much more simple to configure, hell no. Making a new interface on a Omnia works after fiddling with private keys/making a dir etc etc, making it work on a MOX ( both 5.0.3 ) is a no go. Might have to do with WAN ip4 & 6 i think, but no clue. ( edit yes, kill ipv6, and it will install )
OpenVPN is for this nOOb a piece of cake in a normal day to day use.

16

It looks like wireguard could be great, but getting the client end might be more complicated than just sending a config file. That was hard enough for my poor parents to try to get them connected with openvpn when it was working.

I think maybe purging the entire openvpn setup would be the best next step and reinstalling. Since installation mostly happens from Foris, is there a way to make sure I get all the files?

Here are all the packages when I grep opkg list-installed for openvpn:

collectd-mod-openvpn - 5.11.0-7.4
foris-controller-openvpn-module - 0.6.2-3.7-2.0
foris-controller-openvpn_client-module - 0.2-3.7-2.0
foris-openvpn-plugin - 16.6-3.7-3.0
openvpn-hotplug - 0.2-1.0
openvpn-openssl - 2.4.7-2.23
reforis-openvpn-plugin - 1.3.0-3.7-1.0

It looks like dhparam is also one of these packages?

James

17

It appears the update to 5.0.4 has solved this issue.

18

I had same issue in Turris OS 5.0.3 and Turris OS 5.0.4.

I assume it’s a bug in ReForis: I had ReForis installed since Turris OS 5.0. Uninstalling Reforis after upgrading to Turris OS 5.0.4 fixed issue for me.