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
