Bug 477271 - openvpn will not execute route-up script
openvpn will not execute route-up script
Product: Fedora
Classification: Fedora
Component: openvpn (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Steven Pritchard
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-12-19 18:19 EST by william hanlon
Modified: 2009-12-18 02:20 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-18 02:20:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description william hanlon 2008-12-19 18:19:08 EST
Description of problem:
openvpn can not execute a valid route script command given in a config file. When a valid command is provided for the route-up option, openvpn reports "Route script failed: could not execute external program". When the same command is executed on the command line, it executes without a problem, indicating that the problem is not a syntax problem with the command. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Use route-up command in the openvpn config file to add a local route on the server, e.g., route-up "/sbin/route add -net netmask dev tun0"
2. service openvpn start
3. route -n indicates the route hasn't been added. /var/log/messages gives the error "Route script failed: could not execute external program".
Actual results:
The routing table on the server is not updated properly and the openvpn server will not properly route packets from VPN clients to the server and vice versa. (in my configuration my server is also the router for the VPN).

Expected results:
An entry should be placed in the routing table to look like:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface   U     0      0        0 tun0

Additional info:
This configuration file and these route-up commands worked on the version of openvpn provided with Fedora 9. Now they just stopped working when I installed Fedora 10. For now, after I start openvpn if I just copy-paste the command provided for the route-up option, the route is added with no complaints and the VPN works as expected, so there is no problem with the route or the syntax of the command.

I tried running openvpn with "verb 11" option to get the most debugging info possible, but there is not more information as to what openvpn is actually trying to do when executing the route-up option.
Comment 1 Steven Pritchard 2008-12-19 18:30:05 EST
How exactly are you running openvpn?

I have a feeling this is related to bug #458594, but the work-around there only works if you are using the openvpn init script.
Comment 2 william hanlon 2008-12-19 20:53:52 EST
(In reply to comment #1)
> How exactly are you running openvpn?

I'm using it as a routing VPN, using tun devices. The VPN server also routes the private packets by NATting as well. It works fine and I've never had a problem with it until the installation of Fedora 10's version of openvpn. Everything worked as expected after the new install except the addition of this route to the routing table. It is adding something to the routing table, but it just doesn't seem to be able to use the route-up command properly.

In my logs I see it adds an entry to the routing table:
Dec 19 18:40:38 gizmo openvpn[4428]: /sbin/ip addr add dev tun0 local 192.168.10
0.1 peer

I think it's being done by this entry in the config file:

Here's the entry in the routing table:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface UH    0      0        0 tun0

> I have a feeling this is related to bug #458594, but the work-around there only
> works if you are using the openvpn init script.

I have tried setting script-security to 3, which is the most permissive level, and it doesn't help correct the problem.

In my config file:
script-security 3
# route to be established on the server
route-up "/sbin/route delete -net"
route-up "/sbin/route add -net netmask dev tun0"

I see in my logs:
Dec 19 18:35:25 gizmo openvpn[4375]: NOTE: the current --script-security setting
 may allow this configuration to call user-defined scripts
Dec 19 18:35:25 gizmo openvpn[4375]: WARNING: the current --script-security sett
ing may allow passwords to be passed to scripts via environmental variables
Dec 19 18:35:25 gizmo openvpn[4375]: Route script failed: could not execute exte
rnal program
Comment 3 william hanlon 2008-12-20 01:10:41 EST
I grabbed openvpn-2.1-0.29.rc15.fc10.i386 from the testing repository and it resolves the problem.
Comment 4 Alexander Kabakaev 2009-05-30 11:54:35 EDT
Still had a problem with Fedora 10 and its openvpn-2.1-0.29.rc15.fc10

The only solution was to use additional option in client.conf:
script-security 2 system

It didn't work without the "system" in the end.
Comment 5 Bug Zapper 2009-11-18 05:31:39 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 6 Bug Zapper 2009-12-18 02:20:43 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.