Connection to the darknet and possible leaks (forum version)

[Operandi]

Hello there.

A few days ago I have contacted the cryptostorm support via e-mail, asking them a few questions. Per their suggestion I am re-posting the Q&A here at the forum. I'm not sure whether I should have started a separate topic for each question, so I'll just paste all of them here. Feel free to split the topic if needed.

NOTE: I'll post in the following format: "My inquiry (in italics)" / "cryptostorm support's reply" / "My comment (if any)".

[...] I use OpenVPN with default GUI, the OS is Windows 7.

Not sure if you mean the "raw" OpenVPN GUI for Windows... or our newly-released Windows network widget. Either way, answers are (more or less) the same...

Just to clarify: I meant the former.

1. TAP-Windows Adapter reports the following: Status: "Unidentified network"; Connectivity: "No Internet access". Even though everything seems to work just fine. There seems to be a lot of OpenVPN users experiencing the same issue; most likely just another one of Windows' antics. How do I fix this issue? Does it even need to be fixed?

Windows is indeed a bit erratic about such things. Most often, we see these odd status messages if there's multiple TAP adapters active on a Windows install. If you want to do a "clean-up," then manually uninstall ALL TAP adapters, reboot, and then install the widget (which will pull in the most current TAP drivers, automatically). Those old TAP drivers (if that's what this is) can cause all sorts of problems, big and small.

I'm not sure about this, since I do not have any TAP adapters installed aside from the OpenVPN one.

2. Is it normal for physical NIC to exchange any (unencrypted) packets after the OpenVPN session has been initiated?

Yes, it must in most setups due to DHCP. That's why there's a pushed server-side directive to "bypass_DHCP" - otherwise, your Windows machine couldn't talk to your local router, get a local (non-public) subnet IP address assignment, and thus complete the first "hop" of any transfer of packets to the internet, encrypted or not. Only a dedicated IP could avoid all unencrypted packets of this sort, and of course those DHCP plaintext packets are running on a subnetted, non-routable private IP-block and thus, by definition, cannot "leak" onto the public internet.

3. Do the differences between the settings of a hardware NIC and an OpenVPN one matter? E.g., if I have IPv6 disabled at my physical NIC, should I disable it for TAP-Windows Adapter, as well?

In this context, hardware NIC trumps all. The "virtual" NIC exists "upstream" (conceptually) from the hardware adapter itself. For example, if the hardware NIC is powered off, no virtual NIC in the world can manage to pass packets off the machine!

Mostly, we suggest leaving the TAP adapter alone. It's somewhat closely mated to the Windows network stack, which is itself... moody, basically. The routing table edits going on between the TAP adapter, OpenVPN, and Windows are complex, erratic, and not always optimal. We're actively working on some client-side scripting that does its best to enforce order on the way Windows handles spin-up/tear-down of local routing tables & associated metrics, during secure sessions, as the "default" behavior is not always ideal. Hopefully, that will be ready for public beta testing in 1.0

This is also the issue directly targeted by our (still in alpha testing, internally) Leakblock packet-management utility for Windows.

4. I noticed multiple blocked connection attempts on port 137 in my firewall logs. If I'm not mistaken, it is related to NetBIOS over TCP/IP. Are these connections required for something to work properly? If not, then would it be safe to disable NetBIOS in the adapter settings altogether?

NetBIOS is the spawn of Satan.

Ok, well, that's probably not how the tech folks would say it but in this context it's both a security risk (in a dozen really serious ways) and unnecessary for ANY "WAN" network functionality. It was created by MS to facilitate LAN network sharing, and it's... actually half decent at that. Decent, even. But it was never designed with any security in mind - it's a LAN tool, so fair enough. Translating NetBIOS out onto the wider internet is just a tragedy waiting to happen. Don't be that guy... the guy who leaves NetBIOS ports open, and sees his entire machine hijacked remotely for botnet use (yes, that's quite likely to happen via automated portscans and related vulns).

Most folks we know disable NetBOIS on physical NICs unless they have really, really good reasons to need Windows-proprietary sharing on the LAN. Even so, far better to set up LAN sharing via proper TCP/IP, via the router/switch locally, and kill the Spawn of Satan. Nowadays, doing so isn't actually too complex in the Windows ecosystem.

(Did we mention that W7/8 default to "share all media on my hard drive via NetBIOS" in most standard install configurations? Does that sound bad, insofar as NetBIOS is allowed to reach out to the internet? It should... because it is!)

Hehe, nice one. Though, I'd like to add that at the moment of asking I already had NetBIOS over TCP/IP disabled at my hardware NIC, but not at the TAP adapter. When I tried to connect to the darknet for the first time I noticed a lot of aforementioned connection attempts. But after I disabled NetBIOS at the TAP adapter as well, they seem to disappear completely, which is strange. It appears that a software adapter's settings can override those of a physical one, after all (see question #3).

Also: Lol, Micro$oft.

[044hnoor]

I'm not sure whether I should have started a separate topic for each question, so I'll just paste all of them here. Feel free to split the topic if needed.

[marzametal]

Nice Q & A, especially the NetBIOS stuff. If it wasn't for the Harden Windows 7 document, I wouldn't have known I was required to disable some stuff in Device Manager for NetBIOS. So happy!