Re: [Openvpn-users] OpenVPN win7 routing fails (TUN/TAP device doesn't come up), but only sometimes.

[Arthur M. <amu...@gm...>]

On Wed, Mar 30, 2011 at 11:43 AM, Allan Swanepoel <all...@gm...> wrote:
> On Wed, Mar 30, 2011 at 7:24 PM, Arthur Murray <amu...@gm...> wrote:
>>
>> I continue to have occasions when OpenVPN-gui indicates that it is
>> fully connected, and yet the TAP-Win32 adapter does not have an
>> address.
>>
>> Long loop of:
>> Route: Waiting for TUN/TAP interface to come up...
>> TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
>>
>> And never a:
>> TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
>>
> are both sides using windows?
> try the following too:
> in server config, add
> <snip>
> route-method exe
> </snip>
>
> also, check if openvpn is being run as an administrator, check your uac settings
>
>

Earlier in the thread I mentioned that I've tried the "route-method
exe" option without improvement. It is win client to linux host, and I
do run the client (openvpn-gui) as admin.   I had disabled UAC and the
firewall but still experienced the problem.

My crude understanding of the problem is that the IP of the Tap-Win32
device _sometimes_ isn't set (DeviceIoControl (tt->hand,
TAP_IOCTL_CONFIG_DHCP_MASQ)) within the "route_delay_window" for some
unknown reason (which is 30s by default, I have it at 90s), and yet
openvpn still considers it to be a successful connection.  I'm trying
to make that a hard failure so openvpn-gui can attempt a fresh
auto-reconnect and openvpn might have more luck applying the IP
address to the Tap-Win32 device on the next try.

My ugly hack to openvpn-gui (described below) is all I can think of at
the moment, but I hope there is a better and more reliable solution.




verb 3:
Successful:
---snip--
Tue Mar 29 15:23:07 2011 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Tue Mar 29 15:23:07 2011 Route: Waiting for TUN/TAP interface to come up...
Tue Mar 29 15:23:08 2011 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Tue Mar 29 15:23:08 2011 C:\WINDOWS\system32\route.exe ADD 201.1.1.1
MASK 255.255.255.255 192.168.253.1
Tue Mar 29 15:23:08 2011 ROUTE: CreateIpForwardEntry succeeded with
dwForwardMetric1=25 and dwForwardType=4
Tue Mar 29 15:23:08 2011 Route addition via IPAPI succeeded [adaptive]
Tue Mar 29 15:23:08 2011 C:\WINDOWS\system32\route.exe ADD 0.0.0.0
MASK 128.0.0.0 192.168.112.1
Tue Mar 29 15:23:08 2011 ROUTE: CreateIpForwardEntry succeeded with
dwForwardMetric1=30 and dwForwardType=4
Tue Mar 29 15:23:08 2011 Route addition via IPAPI succeeded [adaptive]
Tue Mar 29 15:23:08 2011 C:\WINDOWS\system32\route.exe ADD 128.0.0.0
MASK 128.0.0.0 192.168.112.1
Tue Mar 29 15:23:08 2011 ROUTE: CreateIpForwardEntry succeeded with
dwForwardMetric1=30 and dwForwardType=4
Tue Mar 29 15:23:08 2011 Route addition via IPAPI succeeded [adaptive]
SYSTEM ROUTING TABLE
...
TAP-Win32 Adapter V9
  Index = 20
    IP = 192.168.112.2/255.255.255.192
...
--snip--


Unsuccessful (notice IP of Tap-Win32):
---snip---
... (90 second loop of TEST ROUTES & Route: Waiting for TUN/TAP
interface to come up )
Tue Mar 29 15:17:38 2011 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Tue Mar 29 15:17:38 2011 Route: Waiting for TUN/TAP interface to come up...
Tue Mar 29 15:17:40 2011 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Tue Mar 29 15:17:40 2011 C:\WINDOWS\system32\route.exe ADD 201.1.1.1
MASK 255.255.255.255 192.168.253.1
Tue Mar 29 15:17:40 2011 ROUTE: CreateIpForwardEntry succeeded with
dwForwardMetric1=25 and dwForwardType=4
Tue Mar 29 15:17:40 2011 Route addition via IPAPI succeeded [adaptive]
Tue Mar 29 15:17:40 2011 C:\WINDOWS\system32\route.exe ADD 0.0.0.0
MASK 128.0.0.0 192.168.111.1
Tue Mar 29 15:17:40 2011 Warning: route gateway is not reachable on
any active network adapters: 192.168.111.1
Tue Mar 29 15:17:40 2011 Route addition via IPAPI failed [adaptive]
Tue Mar 29 15:17:40 2011 Route addition fallback to route.exe
 OK!
Tue Mar 29 15:17:40 2011 C:\WINDOWS\system32\route.exe ADD 128.0.0.0
MASK 128.0.0.0 192.168.111.1
Tue Mar 29 15:17:40 2011 Warning: route gateway is not reachable on
any active network adapters: 192.168.111.1
Tue Mar 29 15:17:40 2011 Route addition via IPAPI failed [adaptive]
Tue Mar 29 15:17:40 2011 Route addition fallback to route.exe
 OK!
SYSTEM ROUTING TABLE
...
TAP-Win32 Adapter V9
  Index = 20
   IP = 169.254.167.27/255.255.0.0
...
----snip---









>> I've been trying to think of a simple solution for my users: perhaps
>> modifying the openvpn-gui source to look for the "TEST ROUTES: 1/1" as
>> a necessary line in its console for that session, and if it doesn't
>> see it, force an immediate reconnect (before it even bothers to
>> pretend that the connection is successful)?  It is quite an ugly thing
>> to do, (haven't looked at the source yet but I assume it would be
>> straightforward), but is there any better bullet-proof solution to
>> this problem?     I don't ever want openvpn-gui to present the
>> connection as being successful when it obviously doesn't have the
>> proper routing.