Description of problem: I recently upgraded from openvpn-2.1-0.17.rc2.el5.1 (EPEL stable?) to the latest openvpn-2.1-0.27.rc9.el5 (EPEL testing?) and now the OpenVPN server seems to behave somehow odd/buggy/strange. From the log: Aug 10 17:26:20 int-fw openvpn[19115]: TCPv4_SERVER link local (bound): [undef]:1194 Aug 10 17:26:20 int-fw openvpn[19115]: TCPv4_SERVER link remote: [undef] Aug 10 17:26:20 int-fw openvpn[19115]: MULTI: multi_init called, r=256 v=256 Aug 10 17:26:20 int-fw openvpn[19115]: IFCONFIG POOL: base=10.252.0.4 size=62 Aug 10 17:26:21 int-fw openvpn[19115]: MULTI: TCP INIT maxclients=1024 maxevents=1028 Aug 10 17:26:21 int-fw openvpn[19115]: Initialization Sequence Completed Aug 10 17:26:22 int-fw openvpn[19082]: x.y.z.a:1194 openvpn_execve: external program may not be called due to setting of --script-security level Aug 10 17:26:22 int-fw openvpn[19082]: x.y.z.a:1194 Verify command failed to execute: openssl verify -CAfile /etc/openvpn/PCAcert.pem 2 /C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=PRIVATE/OU=Certification_Authority/CN=Root_Certification_Authority/emailAddress=pca@localhost Aug 10 17:26:22 int-fw openvpn[19082]: x.y.z.a:1194 Exiting After this, the OpenVPN server instance is gone away. Restarting brings no change into this. Version-Release number of selected component (if applicable): openvpn-2.1-0.27.rc9 How reproducible: Everytime, see above. Actual results: Unusable OpenVPN daemon since last update. Expected results: Working OpenVPN daemon again even with latest update state. Additional info: It looks like this problem is described at Gentoo Bugzilla as well, because they've the same: http://bugs.gentoo.org/show_bug.cgi?id=233657 - if I see it correct, setting script-security <n> should solve the problem. So can we somehow set this as default somewhere? Because otherwise we'll kill and/or hurt much of the existing default OpenVPN EPEL setups which we shouldn't do.
See also: http://bugs.gentoo.org/show_bug.cgi?id=234254 When now looking into it, I think we should set "--script-security 2" as the default in the OpenVPN initscript for EPEL 4, 5 and whereever you also updated the OpenVPN package _except_ Rawhide. For Rawhide we can break the stuff, so that the users can get the new behaviour e.g. for EPEL 6 and Fedora 10. But for the existing branches, please introduce no incompatible/breaking changes. And as this popped up the first time on Sunday, I'm really pissed by the change... As far as I understand, we can set "--script-security 2" in the initscript, but users/admins can overwrite this by using e.g. "script-security 0" in their openvpn.conf configuration file, right? So if we set the default, we behave backward compatible and users/admins can use the new feature/extension?! Luckily the Gentoo guys had the problem before, because otherwise Google just tells *nothing* about such a crappy problem. Steven, what do you think about my suggestion?
Or maybe even a better idea, see the following diff of my braindump: --- /etc/init.d/openvpn 2008-08-01 19:10:41.000000000 +0200 +++ /etc/init.d/openvpn.rsc 2008-08-10 19:34:35.000000000 +0200 @@ -153,7 +153,11 @@ . $bn.sh fi rm -f $piddir/$bn.pid - $openvpn --daemon --writepid $piddir/$bn.pid --config $c --cd $work + # Handle backward compatibility, see Red Hat Bugzilla ID #458594 + if [ `grep -c ^script-security $c` -eq 0 ]; then + script_security="--script-security 2" + fi + $openvpn --daemon --writepid $piddir/$bn.pid --config $c --cd $work $script_security if [ $? = 0 ]; then successes=1 else Let us add --script-security 2, if a grep for "script-security" at the beginning of the line of the OpenVPN configuration file was unsucessful. Of course this only has to be done on the affected branches, so everywhere you updated OpenVPN except Rawhide, I would say. This is maybe even more elegant rather the previous suggestion as it doesn't cause an overwrite which could confuse admins and users easily. What do you think?
Okay, there are now two problems for me with the latest OpenVPN you pushed into EPEL: 1. Automagic "--script-security 3" in initscript passing to openvpn once the configuration is not mentioning ^script-security. 2. tls-verify "openssl verify -CAfile /etc/openvpn/PCAcert.pem" doesn't work any longer The first problem we've to follow here. And IMPORTANT: I think, we need "--script-security 3" to have perfect backward compatibility; otherwise I saw some things failing here. For the second problem, I'm going to open another bug report now.
Hello Robert, > Okay, there are now two problems for me with the latest OpenVPN you pushed > into EPEL: > > 1. Automagic "--script-security 3" in initscript passing to openvpn once > the configuration is not mentioning ^script-security. > 2. tls-verify "openssl verify -CAfile /etc/openvpn/PCAcert.pem" doesn't > work any longer > Could you please specify in more detail what means "doesn't work any longer"? It is: a, the certificate verification as a service is not working any more (is broken)? b, the certificate got invalid between upgrading between versions of the openvpn package (due miss to update some part in the certificate DN part)? If a, is the case appearing here, it could be a potential security issue. > The first problem we've to follow here. And IMPORTANT: I think, we need > "--script-security 3" to have perfect backward compatibility; otherwise I > saw some things failing here. For the second problem, I'm going to open > another bug report now. Have you already reported the new bug for the second issue? Jan
Comment #4 was previously mistakenly marked as private... Robert, can you please give more details about what you mean by: 2. tls-verify "openssl verify -CAfile /etc/openvpn/PCAcert.pem" doesn't work any longer Is some invalid certificate getting accepted, or then OpenVPN tries to run this external command, it blows up? Thank you!
Jan and Tomas: I've opened up bug #458600 for the second issue, once I got that I've got two issues. Bug #458612 (marked as blocks in this bug report) is the tracker bug and pointing to both of them. I'll move the bug #458600 parts to there.
(In reply to comment #2) > + # Handle backward compatibility, see Red Hat Bugzilla ID #458594 > + if [ `grep -c ^script-security $c` -eq 0 ]; then > + script_security="--script-security 2" > + fi > + $openvpn --daemon --writepid $piddir/$bn.pid --config $c --cd $work > $script_security OK, I did that almost verbatim in rawhide. > Of course this only has to be done on the affected branches, so everywhere > you updated OpenVPN except Rawhide, I would say. I'm inclined to leave it that way even in rawhide, at least until all of our documentation and samples are updated.
Oh, and for an even more elegant solution, I'm thinking of adding an /etc/sysconfig/openvpn where we can set the default for script-security system-wide. (Maybe default it to 3 on EPEL and 2 on Fedora for now.) That will take a little more code though. In the mean time, this gets us working well enough to push a security update, I think...
For better understanding, wanted to check if there are really two issues present(from comment#0): Aug 10 17:26:22 int-fw openvpn[19082]: x.y.z.a:1194 openvpn_execve: external program may not be called due to setting of --script-security level Aug 10 17:26:22 int-fw openvpn[19082]: x.y.z.a:1194 Verify command failed to execute: openssl verify -CAfile /etc/openvpn/PCAcert.pem 2 /C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=PRIVATE/OU=Certification_Authority/CN=Root_Certification_Authority/emailAddress=pca@localhost Aug 10 17:26:22 int-fw openvpn[19082]: x.y.z.a:1194 Exiting Isn't the second error message (unable to verificate the digital certificate) caused only by the inability of openvpn to call external system command /usr/bin/openssl verify CA-file -- only consequence of improper setting of the security level (security level not allowing executing of external system commands) by openvpn at the startup)? So adding "--script-security 3" to the openvpn initscript would set up the proper security level and would ensure proper function of the certificate validation process?
Jan, I already HAVE "--script-security 3" as parameter set. And using the "script-security 3" command in the *.conf doesn't change anything as well. Maybe the script-security parameter itself is broken, that's possible as well. I am not sure, whether this is maybe case, that's hard to test. But as far as I can see, the script-security parameter seems to work, because I've got another message, when script-security 0 or 1 is set.
This problem doesn't appear to be fixed. An upgrade to rc10 or higher is needed. The problem is, when a script has an argument it doesn't execute. Example: up "./script.sh up" down "./script.sh down" Even with --script-security 3 it will not work. See the ubuntu bug for info. https://bugs.launchpad.net/debian/+source/openvpn/+bug/277447
openvpn-2.1-0.29.rc15.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/openvpn-2.1-0.29.rc15.fc10
openvpn-2.1-0.29.rc15.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/openvpn-2.1-0.29.rc15.fc9
openvpn-2.1-0.29.rc15.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/openvpn-2.1-0.29.rc15.fc8
Eric, I've bumped Fedora and EPEL testing to rc15 in order to solve this issue, as the Fedora package maintainer seems to be some kind of AWOL or at least not interested to work on this. Please test accordingly and let me know what's up with rc15. I'm also using OpenVPN at work and will have a look to this there regarding my other issues, which I mostly now worked around.
Robert, I downloaded your build from Koji and it appears my script problems have been fixed. I'm going to go ahead and close this bug, Thanks!
openvpn-2.1-0.29.rc15.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
openvpn-2.1-0.29.rc15.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
openvpn-2.1-0.29.rc15.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
There is a problem with the patch in comment #2. The $script_security variable is not initialized in the loop, so if your server3.conf contains 'script-security 3 system' it will be overridden by '--script-security 2' on the command line. Fix. [root@rebar init.d]# rpm -q openvpn openvpn-2.1-0.32.rc15.fc11.x86_64 [root@rebar init.d]# diff -u openvpn.orig openvpn --- openvpn.orig 2009-10-23 19:54:06.095386158 -0700 +++ openvpn 2009-10-23 19:54:21.713387134 -0700 @@ -154,6 +154,7 @@ fi rm -f $piddir/$bn.pid # Handle backward compatibility, see Red Hat Bugzilla ID #458594 + script_security='' if [ -z "$( grep '^[[:space:]]*script-security[[:space:]]' $c )" ]; then script_security="--script-security 2" fi
openvpn-2.1-0.30.rc15.el4 has been submitted as an update for Fedora EPEL 4. http://admin.fedoraproject.org/updates/openvpn-2.1-0.30.rc15.el4
openvpn-2.1-0.30.rc15.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/openvpn-2.1-0.30.rc15.el5
openvpn-2.1-0.30.rc15.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
openvpn-2.1-0.30.rc15.el4 has been pushed to the Fedora EPEL 4 stable repository. If problems still persist, please make note of it in this bug report.