search

yarrick / iodine

Official git repo for iodine dns tunnel
https://code.kryo.se/iodine
ISC License
6.25k stars 507 forks source link

iodine fails to find new OpenVPN TAP adapter on Windows #73

Open jbize opened 2 years ago

jbize commented 2 years ago

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);

Xyvir commented 2 years ago

http://build.openvpn.net/downloads/releases/tap-windows-9.9.2_3.exe

I was able to get it working with that specific installer

jbize commented 2 years ago

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

Xyvir commented 2 years ago

It's working for me in win 10 pro 20h2, are you sure the server is set up correct?

20220430_114336

jbize commented 2 years ago

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

jbize commented 2 years ago

I'm running Debian 11, and installed iodine from apt. I am using the following default config:

START_IODINED="true" IODINED_ARGS="-c 172.16.0.1 dnstun.mydomain.org" IODINED_PASSWORD="My iodined password."

Also, I can connect from another Linux machine.

The relevant routes on Windows are:

   172.16.0.0  255.255.255.224         On-link        172.16.0.3    281
   172.16.0.3  255.255.255.255         On-link        172.16.0.3    281
  172.16.0.31  255.255.255.255         On-link        172.16.0.3    281
Xyvir commented 2 years ago

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.

jbize commented 2 years ago

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?

jbize commented 2 years ago

This is what my ipconfig looks like:

Unknown adapter dns-tun:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : TAP-Windows Adapter V9
   Physical Address. . . . . . . . . : 00-FF-AA-2F-B4-12
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::50b6:4af9:66a3:efda%24(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.16.0.3(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.224
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 100728746
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-F3-8F-21-DC-4A-3E-E3-62-5A
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled
Xyvir commented 2 years ago

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

jbize commented 2 years ago

I'm stumped Erik:

Unknown adapter dns-tun:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : TAP-Windows Adapter V9
   Physical Address. . . . . . . . . : 00-FF-AA-2F-B4-12
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::50b6:4af9:66a3:efda%24(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.16.0.2(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.224
   Default Gateway . . . . . . . . . : 172.16.0.1
   DHCPv6 IAID . . . . . . . . . . . : 100728746
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-F3-8F-21-DC-4A-3E-E3-62-5A
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

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?

Xyvir commented 2 years ago

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.

jbize commented 2 years ago

Sorry Tyler.

I don't know how to make this code block folding. My complete IP interface dump is:

ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : LSPTOP-NAME
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Ethernet 2:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek PCIe FE Family Controller #2
   Physical Address. . . . . . . . . : DC-4A-3E-E3-62-5A
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Unknown adapter OpenVPN Wintun:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Wintun Userspace Tunnel
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Unknown adapter dns-tun:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : TAP-Windows Adapter V9
   Physical Address. . . . . . . . . : 00-FF-AA-2F-B4-12
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::50b6:4af9:66a3:efda%24(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.16.0.3(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.224
   Default Gateway . . . . . . . . . : 172.16.0.1
   DHCPv6 IAID . . . . . . . . . . . : 100728746
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-F3-8F-21-DC-4A-3E-E3-62-5A
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Wireless LAN adapter Local Area Connection* 15:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter #4
   Physical Address. . . . . . . . . : 00-82-3F-F1-0B-18
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Local Area Connection* 5:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter #6
   Physical Address. . . . . . . . . : 02-82-3F-F1-0B-19
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Ethernet adapter VMware Network Adapter VMnet1:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet1
   Physical Address. . . . . . . . . : 00-50-56-C0-00-01
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::dd98:c713:a34b:abfb%25(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.189.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 268456022
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-F3-8F-21-DC-4A-3E-E3-62-5A
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter VMware Network Adapter VMnet2:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet2
   Physical Address. . . . . . . . . : 00-50-56-C0-00-02
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::598e:e10:8aa1:5ffc%29(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.2.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 536891478
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-F3-8F-21-DC-4A-3E-E3-62-5A
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter VMware Network Adapter VMnet8:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet8
   Physical Address. . . . . . . . . : 00-50-56-C0-00-08
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::7892:37c1:85e9:737b%31(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.66.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 637554774
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-F3-8F-21-DC-4A-3E-E3-62-5A
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) Dual Band Wireless-AC 3165
   Physical Address. . . . . . . . . : 02-82-3F-F1-0B-18
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::e89e:f7ee:87a9:f83%20(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.200.13(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Saturday, April 30, 2022 3:13:28 PM
   Lease Expires . . . . . . . . . . : Saturday, April 30, 2022 5:13:27 PM
   Default Gateway . . . . . . . . . : 192.168.200.1
   DHCP Server . . . . . . . . . . . : 192.168.200.1
   DHCPv6 IAID . . . . . . . . . . . : 98604135
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-F3-8F-21-DC-4A-3E-E3-62-5A
   DNS Servers . . . . . . . . . . . : 192.168.200.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter Bluetooth Network Connection:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Bluetooth PAN HelpText
   Physical Address. . . . . . . . . : E0-94-67-88-0A-49
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

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.

Xyvir commented 2 years ago

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.

jbize commented 2 years ago

The Iodine.exe output is:

C:\WINDOWS\system32>C:\Progs\iodine-0.7.0-windows\64bit\iodine.exe -r -P "The password here." -d dns-tun dnstun.mydomain.org
Opening device dns-tun
Opened IPv4 UDP socket
Opened IPv4 UDP socket
Sending DNS queries for dnstun.mydomain.org to 192.168.200.1
Autodetecting DNS query type (use -T to override).Opened IPv4 UDP socket

Using DNS type NULL queries
Version ok, both using protocol v 0x00000502. You are user #1
Enabling interface 'dns-tun'
Setting IP of interface 'dns-tun' to 172.16.0.3 (can take a few seconds)...
The following helper DLL cannot be loaded: NAPMONTR.DLL.

Server tunnel IP is 172.16.0.1
Skipping raw mode
Using EDNS0 extension
Switching upstream to codec Base128
Server switched upstream to codec Base128
No alternative downstream codec available, using default (Raw)
Switching to lazy mode for low-latency
Server switched to lazy mode
Autoprobing max downstream fragment size... (skip with -m fragsize)
768 ok.. ...1152 not ok.. ...960 not ok.. 864 ok.. 912 ok.. 936 ok.. ...948 not ok.. will use 936-2=934
Setting downstream fragment size to max 934...
Connection setup complete, transmitting data.
Windows version does not support detaching

It's running as Administrator. I ran it from Windows (8 or 10?) a few years ago with no problems.

Xyvir commented 2 years ago

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

jbize commented 2 years ago

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.

Xyvir commented 2 years ago

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.

jbize commented 2 years ago

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.

Xyvir commented 2 years ago

As in you've tried both ways and neither worked?

Xyvir commented 2 years ago

Here's my route table & iodine.exe checksum:


IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     192.168.20.1   192.168.21.231     40
         10.0.0.0  255.255.255.224         On-link          10.0.0.2    281
         10.0.0.2  255.255.255.255         On-link          10.0.0.2    281
        10.0.0.31  255.255.255.255         On-link          10.0.0.2    281
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
     192.168.20.0    255.255.252.0         On-link    192.168.21.231    296
   192.168.21.231  255.255.255.255         On-link    192.168.21.231    296
   192.168.23.255  255.255.255.255         On-link    192.168.21.231    296
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link          10.0.0.2    281
        224.0.0.0        240.0.0.0         On-link    192.168.21.231    296
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link          10.0.0.2    281
  255.255.255.255  255.255.255.255         On-link    192.168.21.231    296
===========================================================================
Persistent Routes:
  None

PS C:\Users\owner> Get-FileHash .\iodine.exe

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA256          8A5D49139F8A7336A16BFB88DB19CB14D0A42F87CE3A0F867E79566878F2B3F3       C:\Users\owner\iodine.exe
jbize commented 2 years ago

Thanks,

The routing table is consistent with mine, and the hash matches my 64bit copy of iodine.exe.

Xyvir commented 2 years ago

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.

jbize commented 2 years ago

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.

yarrick commented 2 years ago

Can you provide a screenshot showing the root\tap0901 ComponentId inside "SYSTEM\\CurrentControlSet\\Control\\Class\\{4D36E972-E325-11CE-BFC1-08002BE10318}" ?

C will join strings together, so the warnx code is valid.

jbize commented 2 years ago

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.

yarrick commented 2 years ago

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.

jbize commented 2 years ago

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.

yarrick commented 2 years ago

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). Maybe the tunnel is in the wrong mode... https://github.com/OpenVPN/tap-windows/blob/master/src/tapdrvr.c#L31 \ Related openvpn code: https://build.openvpn.net/doxygen/tun_8c_source.html#l06221

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

Mrc527 commented 2 years ago

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.

I've the same issue: link is established but no traffic goes through. No ping answers. 😔 Tried to re-compile both server and client to be sure they're on the same code but no luck on windows. Everything is working fine on Mac / Linux and even on iOS!

yarrick commented 2 years ago

Can you try adding some debug message (like printf("tun data\n"); to https://github.com/yarrick/iodine/blob/master/src/client.c#L735 ?

It would be interesting to know if the tunnel device picks it up or not.

yarrick commented 2 years ago

Please keep this bug for windows issues only, and open a new one if you have some other problem.

jbize commented 2 years ago

Correct, unable to ping (or pass data) between Windows client and Linux (or any probably) server.

sonrixsonrix commented 2 years ago

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

sonrixsonrix commented 2 years ago

http://build.openvpn.net/downloads/releases/tap-windows-9.9.2_3.exe

this seems to solve the issue... I have to test the rest still but the error is gone

Xyvir commented 2 years ago

Did you find my note above? If so I hope it was helpful.

http://build.openvpn.net/downloads/releases/tap-windows-9.9.2_3.exe

I was able to get it working with that specific installer