Opened 13 years ago

Closed 7 years ago

#52 closed Bug / Defect (invalid)

No routing after restart of Win 2003 Server on 2.1

Reported by: Samuli Seppänen Owned by: Samuli Seppänen
Priority: major Milestone: release 2.4
Component: Networking Version: OpenVPN 2.3.2 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: windows service routing


I have installed OpenVPN 2.1rc4 on a Windows 2003 Server (SBS)

Everytime the Server is restarted, I *can* connect to the OpenVPN daemon but could not ping anything, neither internal net nor the Tunnel Endpoint itself which is in my case.

Then, if I simply restart the OpenVPN service, everything works as expected e.g ping to internal machines on the network works and the routing as well.

Tell me what Information you need in addition

Change History (15)

comment:1 Changed 13 years ago by Samuli Seppänen

Originally reported to by Carsten Menke (

comment:2 Changed 13 years ago by Samuli Seppänen

First comment from Carsten:

Problem is still present with 2.1rc7, I've now tested this issue on
2 more Windows Servers where in total I have

1 x Windows 2003 R2 SBS Premium
1 x Windows 2003 SBS
1 x Windows 2003 Enterprise

on all Systems the sympthoms are the same, after System Restart you
can connect to the OpenVPN Endpoint, but no Traffic flows thru, then
restart the Service with (while connected through Remote Desktop

sc OpenVPNSVC stop
sc OpenVPNSVC start

and everything works again. This is not nice, as you have to open
another port on the router to get access to at least the server in
case the Server has been restarted.

Please let me know, if you need additional info, or if I should
perform some tests

Second comment from him:

I have at least found a workaround now:

First here is the workaround:

in openvpn config file use

ip-win32 manual
ifconfig (or whatever your vpn subnet is)

then set the VPN Network Adapter manually to

Now here is what I have else tried:

I first thought this has something to do when the service starts, so
I've added "Spooler" to the Registry Key "DependsOnService" for the
OpenVPN Service, as
the spooler starts really late in the boot up process. However this did
not solve the problem.

The only way to have it working properly is the method described above, so
it seems that there is a DHCP issue with the TAP-Win32 Adapter on the
Server Editions of Windows.

NOTE: You don't have any of these problems if you use OpenVPN on a normal
Windows XP Installation. This just happens with Windows Server 2003 (I
guess with 2000 also, but I do not have an installtion of this)

Also on the net some people tell that the problem is the "Routing and Ras"
Service, this was also not the case for me as on my Installation this
Service was set to "Disabled".

Hope this helps at least tracking down the problem for the developers

comment:3 Changed 11 years ago by Samuli Seppänen

This bug report is very old. Can somebody reproduce this on a recent OpenVPN version and Windows Server 2003+?

comment:4 Changed 11 years ago by Samuli Seppänen

Keywords: windows service routing added

comment:5 Changed 11 years ago by softcat

I can reproduce this bug with OpenVPN 2.3.0 on Windows Server 2008 R2 exactly as described above.

comment:6 Changed 11 years ago by allm

I can also confirm this issue with OpenVPN 2.3.1 (64bit) on a Windows SBS Server 2008 SP2. This is really a big issue. Any solution in preparation? Thanks for keepeing me updated.

comment:7 Changed 10 years ago by l3u

I see the very same bug with (the latest) OpenVPN 2.3.2 on my Windows SBS 2003 server. I would also be very glad to have this fixed!

comment:8 Changed 10 years ago by Samuli Seppänen

Milestone: release 2.4
Version: 2.1.0 /

comment:9 Changed 10 years ago by Samuli Seppänen


comment:10 Changed 10 years ago by xj25vm

I confirm I'm having the exact same problem on Windows Server 2003.

I've come up with a temporary workaround for the time being. I've created a batch script which restarts the openvpn service 5 minutes after the server boots. I've introduced a delay in the script of 5 minutes, as Windows Task Scheduler in Server 2003 doesn't have the option for a task with delay at boot - so that I don't end up restarting the openvpn service too early in the boot process. Here is the contents of the batch file:

REM Cludge to introduce a 5 minutes delay
ping -n 300 > nul

REM stop openvpn service
C:\Windows\System32\net.exe stop "openvpn service"

REM start openvpn service
C:\Windows\System32\net.exe start "openvpn service"

comment:11 Changed 10 years ago by svrmarty

yes it's still an issue with server w2k3 sp2

many thx
this script works great for me.

comment:12 Changed 10 years ago by xj25vm

Just a note to say that after more testing, it seems that a fairly long delay in adding the route also gets around the problem. I have used the following in the openvpn server config, which seems to do it:

route-method exe
route-delay 360

I've also tried 240 (4 minutes) - but that doesn't seem quite long enough, for some reason. Six minutes seems to do it for me. Then again, I guess that might depend on the server load and hardware configuration - so you might want to experiment with different values.

I still don't know exactly why this is is happening and why does it have to wait for 6 minutes after boot, before adding the route, in order to work. But at least I have a server which can do OpenVPN. Maybe the openvpn service on the server should be configured with extra dependencies - to wait for other things to start first - but I wouldn't know which other services it should depend on.

On the other hand, if I could have replaced this server with a Linux box from the beginning, none of this would have been a problem ... oh well :-)

comment:13 Changed 8 years ago by Samuli Seppänen

Could you try whether or not wrapping openvpn.exe into nssm.exe (as shown here) fixes this?

comment:14 Changed 8 years ago by Samuli Seppänen

Owner: set to Samuli Seppänen
Status: newaccepted

comment:15 Changed 7 years ago by David Sommerseth

Resolution: invalid
Status: acceptedclosed

This have been open for over 6 years, we no longer support OpenVPN 2.1 and Microsoft no longer supports Windows 2003 Server. Time to upgrade anyhow. And the newer versions of OpenVPN does some of these things differently anyhow. So closing as invalid.

Note: See TracTickets for help on using tickets.