FS#67180 - [openvpn] openvpn-client@.service fails to start: ExecStart contains config conflict

Attached to Project: Arch Linux
Opened by Jim Davis (metadope) - Thursday, 02 July 2020, 19:19 GMT
Last edited by Toolybird (Toolybird) - Wednesday, 27 September 2023, 07:10 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

I can successfully start my OpenVPN client with a simple command line

#openvpn /etc/openvpn/client/myvpn.conf

But after ^c to exit the testing, and using systemd to subsequently start the same service, the client fails to start.

#systemctl start openvpn-client@myvpn #fails

I've identified the ExecStart line as the problem:

[from /usr/lib/systemd/system/openvpn-client@.service]
ExecStart=/usr/bin/openvpn --suppress-timestamps --nobind --config %i.conf

Specifically, the --nobind directive conflicts with my .conf file (which contains a --local <ip> directive, mutually exclusive with --nobind).

I respectfully suggest that documented configuration options which are application-specific and available to the service user in an external configuration file should not be specified in the systemd .service file.

I have changed my local copy of /usr/lib/systemd/system/openvpn-client@.service to overcome this:

ExecStart=/usr/bin/openvpn %i.conf

But I'm hoping someone upstream will agree that the extra arguments in ExecStart are spurious and need to be removed by upstream.
This task depends upon

Closed by  Toolybird (Toolybird)
Wednesday, 27 September 2023, 07:10 GMT
Reason for closing:  No response
Comment by Christian Hesse (eworm) - Friday, 03 July 2020, 05:36 GMT
Usually the client connects to a remote host and does not bind to a local address. That's why the option is there.
Perhaps you should use openvpn-server@.service if your configuration really needs to bind.
Comment by Jim Davis (metadope) - Friday, 10 July 2020, 13:32 GMT
The --local interface option is useful for clients who are multi-homed, participating in many networks. It reduces spurious udp traffic, and makes reaching a distant, unnamed server easier. It's a *good thing*, for server or client, if you know what you're doing.

There are *many* parameters to an openvpn configuration: Why choose --nobind for the .service file? Is there some value added? Does that parameter forestall problems that a majority of client-users may encounter?

The example client.conf that ships with openvpn already includes the nobind setting, so I really don't understand the addition to the ExecStart.
Comment by Christian Hesse (eworm) - Friday, 10 July 2020, 13:40 GMT
To date I have not used --local in a client configuration, and given that --nobind is still in client service probably others do very seldom only.
Anyway, that was not my decision but is shipped by upstream. Open an issue in upstream bug tracker to discuss it there. Please share the link here.

Oh, and another anyway... Does it work if you use your configuration with the server unit openvpn-server@.service?
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.

Loading...