-
Notifications
You must be signed in to change notification settings - Fork 513
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iodine fails to find new OpenVPN TAP adapter on Windows #73
Comments
http://build.openvpn.net/downloads/releases/tap-windows-9.9.2_3.exe I was able to get it working with that specific installer |
Excellent point Xyvir. That version installs the TAP interface with the legacy Hardware ID. Unfortunately, I'm actually running OpenVPN too. So the workaround is to install the legacy TAP interface first, and then install OpenVPN. (Unfortunately, I still can't get the client to work right on the latest Windows 10. I'm not sure how to get help with that.) |
I'd like to leave this ticket open to get the "root-enumerated hardware ID" issue and the broken warnx statement fixed. I am unable to get the interface to show "IPv4 Connectivity: Internet" and my routing table looks strange. It adds an unexpected route in the subnet to ".... .31" (e.g. 172.16.0.31). And of course I can't ping to the iodined host (e.g. 172.16.0.1). |
I'm running Debian 11, and installed iodine from apt. I am using the following default config: START_IODINED="true" Also, I can connect from another Linux machine. The relevant routes on Windows are:
|
For me in Windows I had to manually set the gateway of the TAP interface to the iodine server IP; 10.0.01 as seen In the screenshot above. |
I tried setting the default gateway of the TAP interface to the iodined server's IP (172.16.0.1), but that didn't help. Is there another way? (Do you mean changing the routes?) Does your routing table look like mine? |
This is what my ipconfig looks like:
|
It looks like default gateway is still not configured I recommend setting it thru control panel > Network sharing center > change adapter settings > right click properties on TAP adapter > ipv4 properties Instead of win 10 metro settings menu |
I'm stumped Erik:
I disabled the Windows Public firewall (and my AV). And I even ran the troubleshooter on the interface. This is failing on 2 Windows 10 boxes (not VMs), my laptop and desktop. Does my route table look right? |
I'm Tyler not Eric, just a random user of the software. I happened to be tinkering with it this past week myself. I can't check my route table right at this moment. Can you provide the ipconfig of your main adapter as well? Also you may want to test it with only the legacy TAP adapter and uninstall the new OpenVPN one in case it's causing an issue. Since it's tunneling thru DNS I wouldn't expect the windows firewall to affect anything. Just let me know, thanks. |
Sorry Tyler. I don't know how to make this code block folding. My complete IP interface dump is:
This machine has VMWare Workstation as well as OpenVPN, lots of interfaces. The other Windows 10 box just has VirtualBox and the OpenVPN 9 (legacy) tunnel, so fewer interfaces. Both machines only have the legacy TAP adapter. Strictly speaking, I wouldn't expect a firewall to do anything either, unless it is running IPS. |
Hmm I don't see anything amiss here. And you still aren't able to ping the gateway address, after you added it in manually and connected with iodine.exe? What does the iodine.exe output look like? Please note the DNS VPN tunnel is only open while iodine.exe terminal window is open and running. You also need to start iodine.exe from an elevated prompt. Just let me know. |
The Iodine.exe output is:
It's running as Administrator. I ran it from Windows (8 or 10?) a few years ago with no problems. |
Oh interesting, I don't get that note about windows not supporting detaching. I can't investigate right now but I'll try to get back to you eventually for some further troubleshooting. Thanks for the patience |
I appreciate your effort very much. I just looked at the code and it seems you won't get that warning if you provide the -f (foreground) option. I hope you can get back to this soon. |
Curious, Did you compile the binaries yourself or download the precompiled ones? Later I can provide a hash of the binary I'm using to verify. |
Both. Yes, I've tried both. I have to break away for this evening too, but I'm going to check to see if EMET or Microsoft Software Protection Platform Service are possible issues. |
As in you've tried both ways and neither worked? |
Here's my route table & iodine.exe checksum:
|
Thanks, The routing table is consistent with mine, and the hash matches my 64bit copy of iodine.exe. |
I'm stumped, I'm inclined to think the issue you are experiencing isn't with the binary or the tap driver itself but something external/ environmental with the Lan / network / server. Or maybe antivirus or other factor on the win10 machines. |
I'm pretty sure of that. It works from a Linux VM. I may set up a Win10 VM and try to back into it to find the problem. |
Can you provide a screenshot showing the C will join strings together, so the |
Hello Eric, Since I used an older OpenVPN tool to create the tap0901 interface before installing OpenVPN-2.5.6-I601-amd64.msi, I don't currently have that problem. But I expect that OpenVPN will continue creating the root-enumerated hardware ID "root/tap0901" rather than using the legacy naming. There was a discussion on an OpenVPN thread about this topic (and working with both HWID forms) several years ago: https://patchwork.openvpn.net/patch/555/ On the warnx code, you are correct, and it certainly compiles; I shouldn't have said malformed. But without the error code, I didn't find the warnings useful. Any way, after opening the tunnel, I still can not ping the server IP from my Windows 10 laptop. |
Some drivers use root prefix. See https://patchwork.openvpn.net/patch/555/ Hopefully helping with bugs #46 and #73.
The latest code should accept the new driver now at least. Can you try to capture some pings on the tunnel interface? If you get anything there, also try to capture some DNS traffic. |
I'd have to uninstall and reinstall OpenVPN to test the "root\tap0901". But the new code certainly looks right. I may do that in the near future when I get a chance, but it's inconvenient right now. Anyone installing OpenVPN on Windows (to get the interfaces and client) should get the "root-enumerated HWID." Great suggestion about the capture. I don't know why I didn't open Wireshark on my tunnel interface before, but when I did, I got unexpected results. I'd be happy to share a PCAP file with you. I saw some unexpected traffic, eg:
But mainly, what I noticed was the lack of expected traffic, the ARP Replies. There were plenty of ARP requests, but no replies. Of course the ping requests had no replies either. |
Seeing different broadcast packets are normal, can you also see the ping packets? I guess they might be missing if ARP fails. The tunnel needs to use tun mode, meaning just raw IP. It should not use tap (which emulates Ethernet and has ARP packets and such). Strange, since this works for most people. Can you check the interface properties to see if that gives any hints regarding tun or tap mode? This comment about tap is also interesting https://superuser.com/a/1597987 Edit: Hmm, looking at the iodine code it already calls ioctl with |
I've the same issue: link is established but no traffic goes through. No ping answers. 😔 |
Can you try adding some debug message (like It would be interesting to know if the tunnel device picks it up or not. |
Please keep this bug for windows issues only, and open a new one if you have some other problem. |
Correct, unable to ping (or pass data) between Windows client and Linux (or any probably) server. |
Hello, I have the same ERROR.... But I am no network expert. I am glad that I came so far because the notes miss any windows syntax for commands (i.e route)... So what must I do to connect iodine on windows to my linux server. And why does it need any OpenVPN or any Tab or whatever? Kind regards Martin |
this seems to solve the issue... I have to test the rest still but the error is gone |
Did you find my note above? If so I hope it was helpful.
|
The Windows OpenVPN installer (OpenVPN-2.5.6-I601-amd64.msi) now creates a TAP interface with a root-enumerated hardware ID (ComponentId = root\tap0901). Iodine (tun.c) only looks for legacy hardware IDs (e.g. ComponentId = tap0901), even if a device name is provided (-d).
Please update the registry device enumeration section to match: tap0801, tap0901, and root\tap0901.
Also: there are several malformed warnx statements in tun.c.
e.g.: warnx("Error opening registry key " TAP_ADAPTER_KEY);
should be: warnx("Error (%d) opening registry key: %s", status, TAP_ADAPTER_KEY);
The text was updated successfully, but these errors were encountered: