Reliably restart OpenVPN service via CLI

[cs1]

Dear all,

I have some inexplicable occasional crashes of the OpenVPN service. Unfortunately it can't simply be reloaded via the web UI because the tunnel device is already existing (ovpnsX). I'm checking the process via Monit which works fine. I want to use a small shell script to remove the interface and restart the service:

Code: [Select]

#!/bin/sh
/sbin/ifconfig ovpns2 destroy
/usr/local/sbin/pluginctl -s openvpn start 2
However, it looks to me like the last command doesn't do anything. My question is: what's the correct command to stop / start an OpenVPN process?

[franco]

No not remove the interface manually.

# /usr/local/sbin/pluginctl -S openvpn

Lists the enabled OpenVPN services including their ID.

Use the right ID for

# /usr/local/sbin/pluginctl -s openvpn restart YOURIDHERE

If restart is not working you're looking at a bigger issue maybe..


Cheers,
Franco

[cs1]

Hi Franco,

if

# /usr/local/sbin/pluginctl -s openvpn restart YOURIDHERE

is the same as restarting the OpenVPN service from the UI, it indeed doesn't work. The logs say that it can't be restarted because the device ovpns2 already exists. Thats the reason why we do an "ifconfig ovpns2 destroy" first. However, we're completely unsure what's actually going wrong. No logs indicate what the trouble is. The process basically dies without letting us know what's wrong.

[franco]

Somehow this is odd because we always preset devices. Maybe this is the down/up issue again?

# /sbin/ifconfig ovpns2 down
# /usr/local/sbin/pluginctl -s openvpn restart 2

Does this work?


Cheers,
Franco

[cs1]

I can't reproduce the failure of the OpenVPN process but if it happens again, I'll give it a try. Thanks for the hint. I'll give feedback as soon as it happened again.

Quick question regarding the ID for restarting the process: it's the one that looks like a long hex UUID, right?

[franco]

For the instances yes, for the legacy client/server not.

Feedback would be nice. If the down is missing we should fix that.


Cheers,
Franco

[cs1]

Yes, I'm using the new instances. I'll send feedback ASAP.

[cs1]

BTW: I think I found a message in the logs which occurs right before the OpenVPN process crashes:

Code: [Select]

Failed to set key: No such file or directory (errno=2)

[franco]

Oh, this is a DCO interface?

[cs1]

Correct. The process dies and there's a message "DCO interface closing".

[franco]

Error number 2 is ENOENT which means it probably fails here in the kernel:

https://github.com/opnsense/src/blob/c11c8261b951154856644958a59366ac01a39db0/sys/net/if_ovpn.c#L856-L862

But not sure why. At least it does not surprise me that it crashes with DCO now.


Cheers,
Franco

[cs1]

I think that we found a way to maybe reproduce it. But we're still investigating. Does it make sense to open a new issue on github and supply information? Or is there already an open issue that we should refer to?

[franco]

I couldn't find a relevant issue in FreeBSD nor pfSense but steps to reproduce I'll gladly take:

https://github.com/opnsense/src/issues/new?assignees=&labels=&projects=&template=bug_report.md&title=

Might also be a problem on the OpenVPN daemon end but filing a kernel bug for now seems sensible since DCO is a kernel feature.


Cheers,
Franco

[cs1]

I love the DCO feature, it gives our users close to wire speed performance. It's rather strange, we have weeks of stable operations with hundreds of simultaneous users. But we're on to something. I'll let you know as soon as we found a reliable way to reproduce the issue.