Windows 10 Spring Creators Update breaks v6v4tunnel

[RDWells]

I just spent a LOT of time with four, count 'em, four "techs" through MS' Virtual Assistant thingie, all of whom wanted to remote control my computer and do stuff completely irrelevant to the problem (I'll spare y'all the gory details), but I FINALLY convinced the fourth one who pretty much summed the issue as a bug which, he wanly suggested, would be looked at by MS engineers who'll send out a fix whenever they dang well feel like it.

So there we have it.  MS "fixed" what ain't broken;  i.e., the netsh command to install a v6v4tunnel doesn't work due to a "bug" and now the geniuses who broke it are gonna fix it. 

So they say.

[tjeske]

So did someone actually login to your machine? What did they try?

Anyway, there's also this thread on TechNet:
https://social.technet.microsoft.com/Forums/windows/en-US/af68159a-87fc-4e39-92a9-c5f209aa4058/will-v6v4tunnel-be-fixed-in-final-version-of-april-2018?forum=win10itpronetworking

It appears as if Microsoft acknowledges this issue. However, I am not sure how serious they treat this issue and how fast it might get resolved. The statement doesn't sound too promising, to hopefully fix it with the next release. And I hope by "release" they mean cumulative update, not Redstone 5. Maybe if more people post over there it'll spark more interest to tackle this bug.

All in all it's probably really only a handful of people affected, since most will have a non-Windows upstream device serving as the local tunnel endpoint.

[RDWells]

So did someone actually login to your machine? What did they try?

Yes, and one wanted to do a System Restore (NO!), another wanted to update the network driver (duh, not the problem), the third did a network reset (which served to do absolutely nothing) and the fourth had me try to use the lengthy version of the netsh command:

netsh interface ipv6 add v6v4tunnel interface=private localaddress= "Your local address" remoteaddress= "remote address given to you" (with the proper numbers put where they belong.)

...which did bupkis.  Same answer:  "no driver selected...."

He (the fourth guy) also wanted to be sure that the mobo drivers were up-to-date.  This is what I meant by irrelevant, and my drivers are ALL up-to-date.  I'm OCD that way.

Anyway, there's also this thread on TechNet:
https://social.technet.microsoft.com/Forums/windows/en-US/af68159a-87fc-4e39-92a9-c5f209aa4058/will-v6v4tunnel-be-fixed-in-final-version-of-april-2018?forum=win10itpronetworking

It appears as if Microsoft acknowledges this issue. However, I am not sure how serious they treat this issue and how fast it might get resolved. The statement doesn't sound too promising, to hopefully fix it with the next release. And I hope by "release" they mean cumulative update, not Redstone 5. Maybe if more people post over there it'll spark more interest to tackle this bug.

All in all it's probably really only a handful of people affected, since most will have a non-Windows upstream device serving as the local tunnel endpoint.

At least I know that it's not just me (or you) having this issue, but for FOUR techs not really having the first clue as to what I talking about is troubling at the least, annoying (and more) at most.  So, looks like we'll just have to twiddle our collective thumbs until MS gets it into gear (without too much grinding?).  The fourth tech said maybe a week or two.  Maybe....

In the meantime, the fourth tech also suggested that as many people as possible submit feedback through their feedback hub so the engineers can spot it.  Yes, that's what he said, so hop to it, readers of this forum.  Light a fire under their bums and let's get this fixed, ASAP.  Here's the link:  https://aka.ms/AA1dxur

P.S. I am not a Windows Insider, I have Window 10 Pro x64 v1803(OS build 17134.48), the April 2018 Spring Update with subsequent quality update of KB4103721 (5/10/18).

[tjeske]

Okay, so I tried to investigate a bit more. At least I found something that was different from 1803 to 1709. If you run this command:

Code Select Expand

netcfg -s n

you will get a list of network adapters, network protocols, and network services. If you scroll through the list you'll find an item called "ms_tcpip6_tunnel - Microsoft TCP/IP version 6 - Tunnels". On 1709 this is listed under "Network Protocols", together with "ms_tcpip6", while on 1803 "ms_tcpip6_tunnel" is listed under "Network Services", while "ms_tcpip6" is still in the "Network Protocols" group.

I was able to delete ms_tcpip6_tunnel and afterwards add it again as a protocol, instead of a service. While on 1709 this was possible with simple administrative privileges, on 1803 I had to run it as "TrustedInstaller". Even though it is listed now in the correct category, it still doesn't work. This is also understandable from the output of "nvspbind.exe", which is a separate tool by Microsoft. The output shows all services or protocols bound to specific network adapters. While on 1709 I can find both "ms_tcpip6" and "ms_tcpip6_tunnel", I can't find the latter on the affected 1803. I haven't found a way yet if it is possible to somehow manually add a protocol. The nvspbind-utility doesn't have an option for this, only to enable or disable already bound protocols.

EDIT:
I think it's because nettun.inf is missing from 1803. I find it on 1709 under HKEY_LOCAL_MACHINE\DRIVERS\DriverDatabase\DriverPackages\ but it's missing completely on 1803. Maybe possible to transfer the INF over and do a manual install.

[tjeske]

Okay, after a little more digging I wanna share my new insight:

It seems to be indeed nettun.inf and the associated driver tunnel.sys which is used to set up the 6in4 tunnel. If you start a tunnel, it will appear as "Microsoft Direct Point-to-Point Tunnel Adapter" in the device manager. The inf-file also holds all the driver information for Teredo, ISATAP, 6to4, and some more. The bad news about this is that 6in4 is therefor indeed the "Direct Tunnels" which where marked deprecated as of 1803 along with all the other IPv6 transition technologies. So I fear that even if it should be able to enable it somehow, Microsoft will not honor this bug and leave it unfixed.

So, I've tried to fix it myself by copying over the driver from a healthy 1709 installation. First pitfall, I can't find to copy the signed driver (inf file misses signture?), and therefor installation is only possible with driver signature enforcement turned off during boot. After that, it installs without error. When I try to set up the tunnel, it still doesn't work, but the error message changed to a simple "Element not found". Checking device manager, I get the Direct Tunnel adapter with a yellow sign and error code 56, manually adding the driver fails with a time out.

What seems still different is that the driver is listed in the registry under some oemxx.inf-key, whereas on an original installation it's simply called nettun.inf. I'll try to copy over some registry keys and see if that helps.

Fingers crossed.

[Hoser13]

Found this after months of researching on an MS site:

https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803-removed-features

IPv4/6 Transition Technologies (6to4, ISATAP, and Direct Tunnels)   6to4 has been disabled by default since Windows 10, version 1607 (the Anniversary Update), ISATAP has been disabled by default since Windows 10, version 1703 (the Creators Update), and Direct Tunnels has always been disabled by default. Please use native IPv6 support instead.

So does this mean there is no way to use a Tunnelbroker tunnel going forward?  Or can someone more technical than me offer a suggestion?

[cholzhauer]

You don't use any of these technologies with HE, HE is 6in4

[tjeske]

But I am pretty certain now that "Direct Tunnels" is 6in4. Why? If I create an IPv6-tunnel with the "add v6v4tunnel", a "Microsoft Direct Point-to-Point Tunnel Adapter" gets added to "Device Manager". Furthermore, after fiddling with the driver for "Direct Tunnels", I was able to change the error message given by netsh.

[tjeske]

Still broken in:

-RS5 insider build 17677.1000

[RDWells]

Following an OOB Quality Update KB4100403 for Win10 to v1803 (17134.81), it's still broken.

Dangit.

[tjeske]

Insider build 17682.1000 still broken, of course.

Add insider build 17686.1003 to the broken list, too...

I can only ask everyone to use Microsoft Feedback Hub to complain about this issue, please.

EDIT:

Windows 1803 build 17134.112 (June 2018 cumulative update) still broken.
Windows insider build 17692.1000 still broken.

[RDWells]

Ladies and Gentlemen, be of good cheer!

I have found a way around the bustage and I credit TJeske for pointing me in the right direction.  I am pleased to report that as a result of what I am about to share that I have an HE tunnel that gives me 10/10 (https://test-ipv6.com) and 20/20 (http://ipv6-test.com) using the HE tunnel script for Win 10.

Here we go:

From where one can find it, obtain the .iso for v1709 and extract it to the folder of your choice.  Within it, search in Windows Explorer for nettun.inf.  You will find several files with either that name or the name within the file name:  (Caveat;  you may have to Take Ownership of the files and the folders in which they go for the copy transfer to work.)

nettun.inf - copied to these folders:  Windows\INF and Windows\WinSxS\amd64_nettun.inf_31b...(etc)
nettun.inf_loc - copied to these folders:  Windows\System32\Driver Store\en-us and Windows\WinSxS\amd64_nettun.inf.resources_31b...(etc)
amd64_nettun.inf.resources_31bf3856ad364e35_10.0.16299.15_en-us_7612c139e588cebb - copied to Windows\WinSxS\Manifests

Now, do a search for tunnel.sys.  You will find:

tunnel.sys - copied to these folders:  Windows\System32\drivers and Windows\WinSxS\amd64_microsoft-windows-tunnel_31b...(etc)
tunnel.sys.mui - copied to these folders:  Windows\System32\drivers\en-US and Windows\WinSxS\amd64_microsoft-windows-tunnel.resources_31b...(etc)

Now, run the tunnel config script from HE, check the results with ipconfig /all, and you should have your v6v4tunnel tunnel in place.

I must caution, however, that I did run into a few snags while going through all this.  You may well have the Microsoft Direct Point-to-point "Adapater" (yeah, that's what it says) but it has a yellow flag by it due to it not recognizing the driver as being digitally signed.  This is the sucky part.  Test the driver by drilling down to Windows\INF to nettun.inf, right click it, click Install and see what happens.  You might get a warning about a third-party driver signature issue in which case you'll have to do this:

Reboot by holding the Shift key while clicking Restart, choose Troubleshoot, then Advanced Options, then Startup Settings.  When the reboot comes around, you'll have a menu from which to choose.  Pick Option 7 Disable Driver Signature Enforcement and let the reboot continue to its end.  Drill back down to Windows\INF nettun.inf, right-click it, click Install, and this time you'll likely get a warning with the option to "continue anyway".  Choose that, and you're good.

If for some reason things get botched and you want to delete the "adapater", go to Device Manager, click View, show Hidden Devices, right click on the "adapater" and Uninstall.  Re-run your HE config script and THIS time things should be good to go.

Having typed all this, I have possibly left out some more caveats with all the trial-and-error I went though before I succeeded, so if there are any snags you hit along the way, I'll gladly try to walk/talk you through a solution.

Good luck, folks, and happy IPv6ing!

[tjeske]

That sounds interesting. And quite similar to my approach. No idea why I had no success :(

Anyway, I guess with this method you have to turn driver signature enforcement off with every boot? Maybe an alternative for that would be to use a self-signed driver (i.e. to sign a driver with your own certificate, that you create somewhere somehow). Then you only need to turn "testsigning" on, which is much more secure than no signature enforcement at all.

Although I wonder what breaks the certificate of the old driver? Shouldn't it still be fine with MS old driver? Maybe if we also swap out tunnel.sys? Or does it need to be packed with the .cat-file and installed from there?

[RDWells]

That sounds interesting. And quite similar to my approach. No idea why I had no success :(

Anyway, I guess with this method you have to turn driver signature enforcement off with every boot? Maybe an alternative for that would be to use a self-signed driver (i.e. to sign a driver with your own certificate, that you create somewhere somehow). Then you only need to turn "testsigning" on, which is much more secure than no signature enforcement at all.

Agreed, and as it has turned out, yes, I had to turn off driver signature enforcement with a subsequent reboot.  Grrr....

Although I wonder what breaks the certificate of the old driver? Shouldn't it still be fine with MS old driver? Maybe if we also swap out tunnel.sys? Or does it need to be packed with the .cat-file and installed from there?

Yup, you'd think that tunnel.sys from v1709 would be fine, but noooo.... It's the one I used to replace the one in v1803.  If you find a suitable replacement and its source, I'm sure you'll let us know.  I'm thinking I can locate the v1803 version of it and replace the one from v1709.  Worth a shot, ya think?  It just might solve the driver signing issue.  No time right now to test that but I'll give it a go and see what happens.

[tjeske]

Sorry, I didn't fully understand your answer.

So did you take the tunnel.sys from 1709 and copied it to the 1803 installation? Or did you just leave the tunnel.sys from the 1803 installation?

I just tried copying the nettun-files, but it didn't solve it for now. But I also messed up my registry during my first tries. Fortunately I am just experimenting inside a VM until I find the proper method.