No routing after restart of Win 2003 Server on 2.1

[Samuli Seppänen]

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 192.168.254.1 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

[Samuli Seppänen]

Originally reported to SF.net by Carsten Menke (​http://sourceforge.net/users/bootsy52).

[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
Session)

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 192.168.254.1 192.168.254.2 (or whatever your vpn subnet is)

then set the VPN Network Adapter manually to

192.168.254.1
255.255.255.252

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

[Samuli Seppänen]

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

[softcat]

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

[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.

[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!

[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 127.0.0.1 -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"

[svrmarty]

yes it's still an issue with server w2k3 sp2

many thx
this script works great for me.

[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 :-)

[Samuli Seppänen]

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

[David Sommerseth]

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.