The openvpn (2.0-r1) initscript leaves it start function after openvpn is started but before the connection is completely up (it takes a couple of seconds). This breaks initscripts that get executed directly after openvpn and that depend on the vpn network. A possible solution is this patch (patched against /etc/init.d/openvpn from 2.0-r1): ----------------------------------------------------------------------------- 36a37 > COMPLETELYUP=`false` 40a42,56 > > CONNECTIONTESTS=0 > while [ ${COMPLETELYUP} -gt 0 ] && [ ${CONNECTIONTESTS -lt 5 ]; do > if [ -f ${VPN}/onlinecheck ]; then > ping -c 3 `head -n 1 ${VPN}/onlinecheck` >& /dev/null > COMPLETELYUP=$? > CONNECTIONTESTS=`expr ${CONNECTIONTEST} + 1` > else > COMPLETELYUP=`true` > fi > done > if [ ${COMPLETELYUP} -gt 0 ]; then > ewarn "Openvpn started without problems but the host in" > ewarn "${VPN}/onlinecheck is unavailable." > fi ----------------------------------------------------------------------------- This patch will let /etc/init.d/openvpn ping a system on the vpn 3 times and if that system replies on one of these pings then the start function will exit. If that system doesn't reply it will try the pings again (5 times total) and then exit start while printing a message that the system is unavailable. Sorry that I didn't place the patch in a attachement, I can`t find how to do it. Reproducible: Always Steps to Reproduce:
I forgot to mention that i only wrote the patch, I still have to test it. Also, I discovered that you can create attachment after the bug is created so i will put the patch in attachement because it's unreadable like this.
Created attachment 62978 [details, diff] Patch for initscript of openvpn 2.0-r1 to check connection after the vpn in launched
Created attachment 63079 [details, diff] new and tested version of the patch without bugs I had the time to actually test the patch, so I did it, fixed a bug, wrote some comments and made a better patch with context
Created attachment 63607 [details, diff] even newer version I asked someone else to test it, he found another a bug, so I created a new patch with the bugfix plus some extra info for the administrator of the system
Created attachment 63640 [details, diff] yet a another new version yet another bugfix
I have a similar problem as the bug reporter poster and would like to support his suggestion to change that ebuild in a way that it waits until the VPN devices and routes are up.
You can use baselayout-1.12.0_pre9-r1 to create tun/tap interfaces if you emerge sys-apps/usermode-utilities. As openvpn depends on the "net" service, the tun/tap interfaces are guaranteed to be up and configured before openvpn even starts. The only downside of this is that you cannot use the "server" configuration directive - instead you have to configure the ip pool and other things manually. See the openvpn man page for how to do this. Closing as WONTFIX