Server configuration file generation broken

[Felix-Franz]

The generation of the file /etc/openvpn/server.conf is broken. Wrong data is generated due the command execution of omv.

generated file

port 1194
proto udp
dev tun
ca "/etc/openvpn/pki/ca.crt"
cert "/etc/openvpn/pki/issued/FelixNAS.crt"
key "/etc/openvpn/pki/private/FelixNAS.key" # This file should be kept secret
dh "/etc/openvpn/pki/dh.pem"
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 169.254.0.0 192.168.72.0
255.255.255.0"
;push "redirect-gateway def1 bypass-dhcp"
;client-to-client
keepalive 10 120
comp-lzo
plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so login
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log
log /var/log/openvpn.log
verb 2
mute 10
crl-verify "/etc/openvpn/pki/crl.pem"

# Extra options

correct file

port 1194
proto udp
dev tun
ca "/etc/openvpn/pki/ca.crt"
cert "/etc/openvpn/pki/issued/FelixNAS.crt"
key "/etc/openvpn/pki/private/FelixNAS.key" # This file should be kept secret
dh "/etc/openvpn/pki/dh.pem"
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.72.0 255.255.255.0"
;push "redirect-gateway def1 bypass-dhcp"
;client-to-client
keepalive 10 120
comp-lzo
plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so login
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log
log /var/log/openvpn.log
verb 2
mute 10
crl-verify "/etc/openvpn/pki/crl.pem"

# Extra options

differences

Change line 11/12 from

push "route 169.254.0.0 192.168.72.0
255.255.255.0"

to

push "route 192.168.72.0 255.255.255.0"

Use your subnet address instead of 192.168.72.0

System Infromation

• Device: Raspberry Pi 3 Model B
• OMV Version: 4.1.17-1 (Arrakis)
• Kernel: Linux 4.14.79-v7+

Tested with two different installations of omv 4.x on the same device type.

[subzero79]

Can you post the command

ip r s

[Felix-Franz]

sure:

169.254.0.0/16 dev enxb827ebb185ec scope link metric 1000 
192.168.72.0/24 dev enxb827ebb185ec proto kernel scope link src 192.168.72.11

[subzero79]

There is no gateway defined. is that intentional ?

Looks like interface was set up manually and also dhcp intention (but failed dhcp)

So you have two ip addresss assigned to the same interface. The mkconf script is based on one ip per nic that’s why is fetching the first one.

[Felix-Franz]

The first ip should not really exist, there is only one static ip configured.

DHCP is completely disabled on this interface.

[subzero79]

There is something wrong there in your network setup. Can the server transverse a network or reach the internet?

How did you install omv using and rpi image or on top of a Debian install ?

[Felix-Franz]

The server is able to reach the internet, with the fixed configuration file I am able to establish a openvpn connection through the internet.

I have installed omv using the rpi image yesterday.

[subzero79]

doesn’t make sense without gateway and dns that the server has internet.I will have to test this using a rpi. What happens when you swap to dhcp? Does “ip r s” displays a gateway?

[subzero79]

I won’t have time in the next 4 days for testing this. I recommend you to check your boot logs and syslog to see why is the iface getting 2 ip addresses, especially the first one which looks like failed dhcp acquisition.

[Felix-Franz]

Changing the network setting to use the dhcp does not remove the other ip, it just changes the rpi's ip.

default via 192.168.72.1 dev enxb827ebb185ec 
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1 
169.254.0.0/16 dev enxb827ebb185ec scope link metric 1000 
192.168.72.0/24 dev enxb827ebb185ec proto kernel scope link src 192.168.72.161

I have checked boot log and syslog, but I didn't found 169.254 in any entry.

[subzero79]

You need to remove the offending ip address by using iproute2 commands. Reboot and see if it comes back. If it comes back you then is a problem but not the plugin.

If you don’t mind I want to see this

dpkg -l | grep dhcp

[Felix-Franz]

output of dpkg -l | grep dhcp:

ii  isc-dhcp-client                     4.3.5-3+deb9u1                 armhf        DHCP client for automatically obtaining an IP address
ii  isc-dhcp-common                     4.3.5-3+deb9u1                 armhf        common manpages relevant to all of the isc-dhcp packages

For testing purpose I have used a different pi with a new omv image. Just after the installation of the image, the network 169.254.0.0/16 is set.

root@raspberrypi:~# ip r s
default via 192.168.2.1 dev enxb827eb3716d7 proto static metric 100 
169.254.0.0/16 dev enxb827eb3716d7 scope link metric 1000 
192.168.72.0/24 dev enxb827eb3716d7 proto kernel scope link src 192.168.72.119 metric 100

So I deleted this route:

root@raspberrypi:~# ip r del 169.254.0.0/16 dev enxb827eb3716d7
root@raspberrypi:~# ip r s
default via 192.168.72.1 dev enxb827eb3716d7 
default via 192.168.72.1 dev enxb827eb3716d7 proto static metric 100 
192.168.72.0/24 dev enxb827eb3716d7 proto kernel scope link src 192.168.72.119 metric 100 

But after a reboot, the route was added again.

This is not caused by the openvpn plugin, because I have never installed it on this device.

Do you know if this route is needed by omv? I have just opened an issue in the omv repo to clearify this: openmediavault/openmediavault#273

[subzero79]

That route is added usually when an interface has failed to get dhcp, so it self assigns that address.

[hisaha]

I have same issue, I also found some user in below forum. https://forum.openmediavault.org/index.php/Thread/26076-OpenVPN-4-0-3-Options-error-No-closing-quotation/

Line 66 in /usr/share/openmediavault/mkconf/openvpn is "ip r s | grep -Ev default | grep ${1} |cut -d/ -f1".

How about this modification? "ip r s | grep -Ev default | grep -v 169.254.0.0 | grep ${1} | cut -d/ -f1"

[ThomasKaiser]

That route is added usually when an interface has failed to get dhcp

This link local route being present is also a sign of having installed the avahi-autoipd package which will allow a Debian host to function wonderfully without any networking configured and no DHCP server reachable (default on the OMV ARM images and IIRC also on Raspbian and almost any other more user focused Linux distro these days -- it allows the device to fetch a link local address and access other link local devices, in combination with the avahi daemon it will also be accessible using $hostname.local).

Link local routes should simply be ignored when determining routable subnets:

ip r s | grep -Ev "^default|^169\.254\." | cut -d/ -f1

[theOehrly]

I am having issues with that configuration file too. I don't know too much about networking so I don't really know whether that command is right or not. The problem for me is that the OpenVPN server does not even start because ovpn-server[27548]: Options error: No closing quotation (") in /etc/openvpn/server.conf:12 Line 12 is the line you are talking about above. The issue simply seems to be that it is two lines instead of one. This is how it is supposed to be in my file (I guess): push "route 169.254.0.0 192.168.178.0 255.255.255.0"

And this is, what is created when saving in the web interface: push "route 169.254.0.0 192.168.178.0 255.255.255.0" After changing it to one line the server runs fine. I just need to fix that through ssh every time I change the openvpn config in the web interface or it won't run.

[theOehrly]

So currently I still have this issue. The plugin always creates a broken config file and I need to fix it through SSH. I have Openvpn Plugin Version 4.0.3 installed which seems to be the newest version. I can't tell though when this version was released. Should it already contain this fix or not?