Print

[RDWells]

Yes, I took tunnel.sys from v1709 and copied into the v1803 installation.  I tried putting the v1803 version back but I kept getting "element not found" when I ran the HE CMD script.

Registries need not be altered, and just a reminder, the nettun files go as follows:

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

Sadly, the driver is still showing as unsigned.  Darned if I know why, so it looks like we'll still have the unsigned driver thing to deal with upon reboot.

[tjeske]

Thanks. So, I have possibly found a cleaner method. However, the embedded certificate of tunnel.sys (which weirdly is not shown when opening file properties, contrary to other .sys files!) is only valid till Aug 11th, 2018. But all other .sys files of a 1803(!) installation have the same certificate validity. So I don't know what will happen after Aug 11th, 2018. Also, I only confirmed this workaround for now on my insider preview installation running RS5 build 17692. Will report back if it also works on my main machine with 1803 final, or not.

What I have done:

• You need the tool "RunAsTI" (short for "run as TrustedInstaller"), which is needed to edit files in C:\Windows\system32\drivers. It will open a cmd-window with TrustedInstaller privileges. Therefor, you don't need to change ownership or fiddle with any other access permissions. (it's a very useful tool for troubleshooting in general. E.g. it enables you to access ALL keys in the registry, even ones that are hidden from administrator! Unfortunately, the 32-bit version is flagged as virus/hacktool by Windows Defender)
• use the tool to rename the old tunnel.sys (e.g. rename to tunnel.sy_)
• use the tool to copy the tunnel.sys from 1709 into c:\windows\system32\drivers.
• copy the nettun.inf from 1709 somewhere (e.g. desktop, documents folder, download directory, whatever...)
• right-click nettun.inf and click "Install".

That's it. This way it should install fine with the old certificate and you can setup the tunnel as usual. Since it's even signed by Microsoft, not only don't you need signature enforcement turned off, even testsigning mode isn't needed anymore, which further allows you to keep SecureBoot turned on.

However, I don't feel comfortable using this method, as it will suggest to Microsoft that the issue doesn't exist anymore, and it probably won't work indefinitely.

[RDWells]

I'm baffled AF on two counts:

1)  Is the v1709 version of tunnel.sys you use actually signed?  Mine, for some odd reason (even though it's from Microsoft, I think?), is not.
2)  I cannot for the life of me get v1803 tunnel.sys to work at all, even with signature enforcement turned off and right-clicking nettun.inf "install", with it saying the action was completed.  I keep getting "element not found"

I searched high and low for ways to sign an unsigned driver and most of them involve a looong process with Windows Development Kit (and one other whose name escapes me) and even then, the instructions were above my pay grade to understand.

So, it appears that even though I followed the command prompt of "bcdedit /set testsigning on" and "bcdedit.exe /set nointegritychecks on" to permanently disable signature verification, it does not "stick" and I am left with having to go with Shift+Restart>Troubleshoot >> Advanced Settings >> Windows Startup Settings >> Restart>7 Disable Signature Verification EVERY time I reboot in order for the driver tunnel.sys to remain loaded.  SecureBoot is turned off, btw.

[tjeske]

You can't permanently disable driver signature enforcement without any additional tools. One example seems to be "ReadyDriver". But, since Windows 10 the Windows Development Kit is not needed anymore. Then necessary tool is included with PowerShell: "New-SelfSignedCertificate". See the last answer here:
https://stackoverflow.com/questions/84847/how-do-i-create-a-self-signed-certificate-for-code-signing-on-windows

Regarding your other comments:
1) I don't know for sure. When I open the file properties for tunnel.sys (new or old) it's missing the "Digital Signatures" tab. However, I was able to extract a certificate from the file. So I think it does have one. Why it doesn't show? No clue...
2) did you also edit nettun.inf to reflect the correct version number (i.e. 10.0.17134.1)?

But whenever I tried to edit nettun.inf it resulted in missing certificate. I wonder what certificate checks nettun.inf integrity. Must be somewhere else, cause the .inf-file doesn't contain an embedded signature.

BTW: I haven't been able to install the 1709 version without testsigning. It still complains about missing signature of 3rd party INF. So I guess testsigning is necessary, which also means no SecureBoot.

[Hoser13]

I just can't find an iso for 1709 anywhere that seems to look safe.  Lots of odd websites, but nothing official looking.

[RDWells]

I just can't find an iso for 1709 anywhere that seems to look safe.  Lots of odd websites, but nothing official looking.

I can only suggest what I used, since MS does not offer a direct link to the desired .iso, (and most of the .iso files I did find did not contain the necessary files) and that is this:

http://sihmar.com/download-windows-10-build-16299-15-esd-files-direct-links/

...which will give you several flavors of v1709 in .esd format.  No need to convert it to .iso, so save yourself the trouble.

Here's where it sucks eggs;  this file (I chose Win10 Pro x64, ~3GB) is extractable by, say, 7-zip (which I use) but it expands to 130GB so hopefully you have enough room to do that.  Just to extract took me just under 51 minutes.

Then, you'll have 12 numbered folders, each of which (except for Folder 1) will contain the necessary files to copy (as mentioned in a previous post) which also means you only need one of them.  Just choose one and delete the rest which will take another lengthy amount of time.

[tjeske]

Windows 1803 build 17134.112 (June 2018 cumulative update) still broken.
Windows insider build 17704 still broken. <- newest release after bug bash event.

BUT: I have some seemingly insider info that a fix is supposedly scheduled for the next build 17709. I don't have more proof than this anonymous statement, but mentioning a future build number makes it seem rather legit to me. EDIT2: Also, supposedly only for the insider build and following. 1803 probably won't receive a fix.

[tjeske]

So, insider build 17711 is out. It seems fixed. But it looks like it's not nettun.inf anymore. However, I am not 100% sure, as I just updated the previous 17704 insider build where I applied the manual fix. Will do a fresh install now and report back. Also note that this hasn't been mentioned in the changelog.

[tjeske]

Okay, great! Microsoft really did it in insider build 17711 and brought back native 6in4 tunneling!

However, nettun.inf isn't there anymore, tunnel.sys is though. But I am not sure if it is still being used, because there's no device visible in device manager anymore. The tunnel works, it's device is listed using netsh. But I have no idea which driver is being used now. It just works™. Probably I'll have a look in the registry, but for now I am satisfied.

Let's hope they keep it running! Again: it's probably not going to be backported to RS4 aka 1803. Everyone who wants to use it needs to update to become a Windows insider and update to the current build. Fortunately, insider builds seem already quite progressed and I'd even use it in a mild production environment. But that's for everyone to decide on his/her own.

[Hoser13]

I was able to get the tunnel running on 17713, but could only get a score of 16/20 with a warning that my browsers could not fall back.  Problem is, as soon as I reboot, the tunnel is gone.  Oh well.  Back to the drawing board.

[tjeske]

I think that's always the case that the tunnel is lost upon reboot. That's why I setup a netsh-script with task scheduler to be run on every boot. Browsers not being able to fall back could be firewall blocking certain types of ICMPv6 pings, I believe.

This is what my script looks like:

Code: [Select]

pushd interface ipv6

add route prefix=::/0 interface="IP6Tunnel" nexthop=2001:470:xxxx:zzzz::1 publish=No
set interface interface="IP6Tunnel" forwarding=enabled advertise=enabled nud=enabled routerdiscovery=disabled
add address interface="IP6Tunnel" address=2001:470:xxxx:zzzz::2/64

### Forwarding and advertising
# for LAN segment
add route 2001:470:xxxy:zzzz::/64 "Ethernet" publish=yes valid=1d preferred=1h
# for VMs running on local system
add route 2001:470:xxxy:zzzz::/64 "VirtualBox Host-Only Network" publish=yes valid=1d preferred=1h

set route ::/0 "IP6Tunnel" publish=yes valid=1d preferred=1h

set interface "Ethernet" forwarding=enable advertise=enable otherstateful=disable
set interface "VirtualBox Host-Only Network" forwarding=enable advertise=enable otherstateful=enable

set interface "IP6Tunnel" forwarding=enable

I also have a tiny DHCPv6 running on my system for stateful-IPv6 (that's why I wrote otherstateful=enable above). The piece of software is called "dibbler" and works like a charm! This is needed if you also want to publish a DNS server to your clients, cause Windows doesn't support RDNSS (at least it didn't two years ago). Otherwise, IPv4-DNS usually does report IPv6-records as well, so lookups will still need a working IPv4.