Proper Initialization of TAP Windows Driver V9.9 (TAP_IOCTL_CONFIG_TUN)

[Aleksandar Kanchev]

Hello,

I investigated the problem further and found out that the tun main
loop wasn't being able to read any data from the tun interface.
The problem seems to be in open_tun() @ tun-win32.c. There is a
TAP_IOCTL_CONFIG_TUN DeviceIoControl call which should set the IP and
Netmask of the device. Unfortunately there isn't any visible effect
after this call. I removed all setup code from the script and after
successfully connecting to my providers vpn server ipconfig /all
showed the interface with some dummy ip/netmask and dhcp was enabled.
When I remove the TAP_IOCTL_CONFIG_TUN call, then
GetOverlappedResult() is able to finish and some packages of sizes 42,
66, 54 and 62 are being read.

I was following the source code of OpenVPN but in my case the
interface is always initialized in dhcp mode and not peer-to-peer. The
TAP Windows driver doesn't seem to be documented very well but I came
to this simple example:
https://svn.ntop.org/svn/ntop/trunk/n2n/n2n_v2/win32/wintap.c

My questions is if it's correct to remove the TAP_IOCTL_CONFIG_TUN and
will openconnect function properly after that?

Cheers


2014-05-06 10:38 GMT+02:00 Aleksandar Kanchev <aleksandar.kanchev at gmail.com>:
> Hello,
>
> I followed the instructions of David Woodhouse and built openconnect
> 5.99 for windows (tried 32 and 64 bit versions) inside my fedora vm:
> http://lists.infradead.org/pipermail/openconnect-devel/2014-March/001728.html
>
> I also installed the latest OpenVPN 2.3.4 (x86_64-w64-mingw32) and got
> the TAP-Windows driver version 9.9 installed too. Connecting with
> openconnect to my firm's cisco vpn server was easy, since the
> authentication is based on login and password only. I modified the
> vpnc-script-win.js to run only the following lines on "connect":
>    run("netsh interface ip set interface \"" + env("TUNDEV") + "\" metric=1");
>    run("netsh interface ip set address \"" + env("TUNDEV") + "\" static " +
>           env("INTERNAL_IP4_ADDRESS") + " 255.255.255.255");
>    if (!waitForInterface()) {
>       echo("Interface does not seem to be up.");
>    }
>    run("route add 192.168.50.0 mask 255.255.255.0 " +
> env("INTERNAL_IP4_ADDRESS"));
>
> Everything seems quite straight forward and easy but I couldn't ping
> the internal network 192.168.50.0 even though the route seems to be
> added. I made sure to run openconnect as administrator and made sure
> the tap interface was configured properly. If I connect with the cisco
> anyconnect client it automatically sets the INTERNAL_IP4_ADDRESS + 2
> as standard gateway and routes all my traffic through the vpn tunnel.
> I also tried to setup a configuration like that but it didn't help
> either.
>
> The tap driver is installed properly since I'm also using OpenVPN on
> the same windows 8.1 machine to connect to another vpn server. To
> verify that openconnect is capable of connecting to my firm's cisco
> vpn server I tried it under my fedora vm and it worked properly.
>
> I'm out of ideas on what might be the cause for the tap driver/routing
> not working. I also tried the openconnect --dump-http-traffic option
> and noticed that pinging a host within the 192.168.50.0/24 network
> wouldn't cause any extra traffic. Couldn't it be something wrong with
> the interface between the tap driver and openconnect on windows 8.1?
>
> Cheers