Hi Martin, no problem. Exchaning the file "completely" might be too much unless we can reason all the changes. Some I'd think were made in Debian/Ubuntu for valid reasons and should be kept. So if I might ask you continue your test for combinations of the delta.
I only reordered things to make it more readable - overall the change from Ubuntu/Debian to upstream would be: --- debian.openvpn@.service 2018-08-28 14:58:25.145712079 +0200 +++ upstream.openvpn@.service 2018-08-28 15:03:00.221966742 +0200 @@ -3,28 +3,23 @@ PartOf=openvpn.service ReloadPropagatedFrom=openvpn.service Before=systemd-user-sessions.service -After=network-online.target -Wants=network-online.target Documentation=man:openvpn(8) -Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage +Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO [Service] -Type=notify +Type=forking PrivateTmp=true WorkingDirectory=/etc/openvpn ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --script-security 2 --config /etc/openvpn/%i.conf --writepid /run/openvpn/%i.pid PIDFile=/run/openvpn/%i.pid -KillMode=process +KillMode=mixed ExecReload=/bin/kill -HUP $MAINPID -CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE +CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_READ_SEARCH CAP_AUDIT_WRITE LimitNPROC=10 DeviceAllow=/dev/null rw DeviceAllow=/dev/net/tun rw -ProtectSystem=true -ProtectHome=true -RestartSec=5s -Restart=on-failure +ProtectSystem=yes [Install] WantedBy=multi-user.target Let us break this into categories: 1. Distro is better, we should not take this change (in fact we should file upstream issue to change there) -After=network-online.target -Wants=network-online.target -Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage +Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage 2. we already know we want to follow this change in the Distro: -CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE +CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_READ_SEARCH CAP_AUDIT_WRITE => Probably a fusion of the capabilities here eventually 3. I think these are better than upstream, but we need to check which one of it is the reason for your issue -ProtectSystem=true +ProtectSystem=yes (should be a no-op IMO) -RestartSec=5s -Restart=on-failure -KillMode=process +KillMode=mixed These two are in fact copied over from ustraem (remember the actual upstream, not their deb package creation - there I'd hope that these are not the reason) -ProtectHome=true -Type=notify +Type=forking If you could apply #2 in any case and then test the sections of #3 one by one and report back here which one solve it for you that would be great. I realized that all our changes are from upstream actually, see https://github.com/OpenVPN/openvpn/blob/master/distro/systemd/openvpn-server%40.service.in And check which one is closer Ubuntu or the upstream .deb package :-) Never the less, lets find out which difference it is that breaks you. Then we can go upstream with the request to change and adapt here as well. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1787208 Title: Openvpn routing issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1787208/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
