OPNsense Forum
Archive => 23.1 Legacy Series => Topic started by: almodovaris on May 04, 2023, 02:54:06 pm
-
/usr/local/etc/rc.d/openvpn: WARNING: /usr/local/etc/openvpn/openvpn.conf is not readable.
/usr/local/etc/rc.d/openvpn: WARNING: failed precmd routine for openvpn
-
Got it, it needed "allow-compression yes".
-
/usr/local/etc/rc.d/openvpn: WARNING: /usr/local/etc/openvpn/openvpn.conf is not readable.
/usr/local/etc/rc.d/openvpn: WARNING: failed precmd routine for openvpn
We don't use rc(8) system for OpenVPN.
Cheers,
Franco
-
Following update to 23.1.7, all my client instances fail on reboot.
Saving each client config or restarting the respective service resolves the problem, but this does not survive reboot.
The OpenVPN log shows the following for failed clients (log level 5):
FreeBSD ifconfig failed: external program exited with error status: 1
This is following the logged command:
/sbin/ifconfig ovpncX <IP/CIDR-mask> mtu 1500 up
-
Switching to log level 11 reveals nothing further.
I did notice this though (not reported in my previous post):
ioctl(TUNSIFMODE): Device busy (errno=16)
This event doesn't occur upon manual service restart and the VPN comes up...
Perhaps this is a race condition at boot time?
-
No within OpenVPN itself. If you have other tun-based VPNs that might be problematic. But the flow for interface creation should be version-agnostic and there were no such changes in 23.1.7.
Cheers,
Franco
-
I just updated to 23.1.7 an I have the same issue. I use only one OpenVPN tunel. After reboot i see status "Failed" under VPN / OpenVPN / Status. Stopping the openvpn service and starting it again manually makes it connect again and it works fine until next reboot. There was no such issue in 23.1.6.
-
checked on one of my machines, at a first glance this has to do with a change in OpenVPN 2.6. Downgrading openvpn fixes the boot issue (but the backend code isn't compatible in that case).
Will investigate this further now.
Best regards,
Ad
-
At a first glance OpenVPN doesn't play nice here, but I've added a small workaround which might circumvent the issue in https://github.com/opnsense/core/commit/c22f74a78628b681e9a2a2d726fd78b95e32b5fe
In case someone wants to test this locally and report back:
opnsense-patch c22f74a78
On my end this seems to work reliably on reboots.
Thanks,
Best regards,
Ad
-
At a first glance OpenVPN doesn't play nice here, but I've added a small workaround which might circumvent the issue in https://github.com/opnsense/core/commit/c22f74a78628b681e9a2a2d726fd78b95e32b5fe
In case someone wants to test this locally and report back:
opnsense-patch c22f74a78
On my end this seems to work reliably on reboots.
Thanks,
Best regards,
Ad
It works. I rebooted two times just to be sure and both times openvpn client connected with no issues. That was super fast fix. Thank you very much sir.
-
... someone wants to test this locally and report back ...
Thanks Ad. That also worked for me.
Bit of a catch all fix, but probably of some preventative value in an indeterminable number of cases anyway.
-
From the looks of it it seems that OpenVPN trips over itself now with 2.6 likely due to work done for DCO on an upcoming actual FreeBSD 14 release coincidentally sponsored by Netgate/pfSense.
That's all nice, but looking at that open source but also closed source bug report for the same issue I think that playing the open source card without being open source is a very risky idea for everyone using that software as well...
https://redmine.pfsense.org/issues/13613
Cheers,
Franco
-
That's all nice, but looking at that open source but also closed source bug report for the same issue I think that playing the open source card without being open source is a very risky idea for everyone using that software as well...
https://redmine.pfsense.org/issues/13613
Cheers,
Franco
Thats why we are here and not there. Shenanigans like that will backfire hard on them. Opensource community is brutal when it comes to shady stuff like that.
-
From the looks of it it seems that OpenVPN trips over itself now with 2.6 likely due to work done for DCO on an upcoming actual FreeBSD 14 release coincidentally sponsored by Netgate/pfSense.
Until the ovpn-dco kernel mode driver becomes available with inclusion of the FreeBSD 14 source in OPNsense, I was wondering if there was any value in:
- "Hard-coding" the disable-dco generic option for all configurations (presuming it isn't already); &
- Adding an unselectable "DCO - Not yet implemented" option to the "Device mode" field in the GUI.
Not flaming, I actually do agree with @Franco and @alex303 (and probably most here) re Netgate's conduct.
I noticed the OpenVPN source had separate code for the FreeBSD DCO implementation, and I'm assuming the option is available. The typical usage would be to permit legacy clients to connect to a server with the DCO module available. My thoughts were that #1 would perhaps also prevent a client trying to use it via advanced options and #2 would make it clear that it isn't implemented for those trying to enable it.
-
I think the DCO code doesn't even build on FreeBSD 12 and 13 as per the port which is good.. it's only enabled in what is going to be "14". But that doesn't mean that subtle changes cannot present itself as hard regressions. It's probably only a bug ticket away, but I've had not the best experience with upstream contributions to OpenVPN (possibly my fault and I don't want to sink more time into it).
Cheers,
Franco