Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  


Welcome to Hurricane Electric's forums!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - tjeske

Pages: [1] 2 3
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]
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.

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.

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

Anyway, there's also this thread on TechNet:

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.

Update: no news!

Still broken in final 1803 build 17134.48

Also still broken in
-1803 insider build 17661.1001
-1803 insider build 17666.1000
-1803 insider build 17672

No, cause I need this machine to be directly connected to the network.

I thought about the VM stuff, but I'd need a VM that forwards proto 41 from host to guest. And VirtualBox doesn't seem to be doing that.

I also posted in Windows forums, they seem to be aware of this issue now, and are also considering it an issue, and not a "feature for removal". But at least in insider build 17661 it's not fixed. To be honest, I don't know exactly how it works with the build numbers and possible intermediate patches. So, I am still just gonna sit it out.

Is there maybe a 3rd party client software for 6in4 tunnels? I couldn't find anything. All the results are just saying about v6v4tunnel and how to do it from Windows.

I am really pissed. The one time that I directly deleted the previous Windows version after upgrading seeing it booted fine. And now this shit. And I don't have the time to reinstall Windows 10 at the moment.

Those commands worked in the previous build but will not work now.  What is concerning is the line "There is no driver selected for the device information set or element."

For some reason, the v6v4tunnel-driver/binding/whatever-its-called is not correctly installed anymore. It's actually part of netip6.inf, which is for IPv6 in general, but it doesn't seem to work anymore. No idea if this can be manually fixed. I don't know the commands. Tried reinstalling the inf-file with no success.

netcfg -v -m (optionally use  "netcfg -v -m | clip" which will copy to clipboard so you can paste output to notepad)

This shows at least one line "Binding entry ignored since it is Type:5 Name:ms_tcpip6_tunnel". So, Windows somehow is aware that this tunnel exists in theory. Maybe they even disabled it intentionally, since MS says they don't want to actively support IPv6-transition mechanisms anymore and instead push people towards using native IPv6. See for yourself:

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

However, this doesn't mention "6in4". Or is that what "Direct Tunnels" are? In that case, it should be possible to enable it somehow.

Edit: if you need v6v4tunnel to work, DON'T update to 1803!!! Just stay on 1709.

Seems like this problem slipped by unnoticed. Just "skipped ahead to the next Windows release" Insider 1803 build 17655.1000, and it's still broken.

I strongly advise anyone not to upgrade past Windows 1709 at the moment, if you need to start the tunnel from Windows. Maybe this bug will cause more noise once the April 2018 update goes live, and hopefully will result in a quicker fix then.

I set a test machine to Windows Insider on the Release Preview ring. Build 17134.1. Problem still existing. I'll now try Slow Ring, and if that fails Fast Ring. From what I've found out, this issue exists at least since insider preview build 17046.

Not really. I am not even registered for the insiders program. I was just quick to download ISO file before Microsoft found some problem and decided to withdraw the final status again, and to delay the update until further adjustments have been made. I am currently on build 17133.1. Well, of course it could be possible that "some problems" also include the v6v4tunnel, but I have doubts about that.

IPv6 on Windows / Windows 10 Spring Creators Update breaks v6v4tunnel
« on: April 20, 2018, 06:16:24 AM »
It seems there's a serious problem. After updating to Spring Creators Update, my tunnel is not working anymore. I cannot setup the tunnel device (adding v6v4tunnel fails). I fear this will not be resolved in the final build of the newly named April 2018 update. For now, I strongly advise against updating.

Apparently, Windows Spring Creators Update aka Redstone 4 aka 1803 breaks IPv6-tunneling. Even in the final build. Let's hope 1804 will fix it. I'll sit it out for now, as I have no time to do a full reinstall (and I deleted the rollback version already).

Probably it's not DMZ, but exposed host. Maybe your router doesn't forward IP-protocol 41 (protocol, not port!). What's your router model?

Maybe if you're using IPv6 privacy extensions, you'll get lots of different addresses for your device(s), and all seem to need an entry in those geolocation databases.

I have the same problem with domain. How was your friend able to help you out?

It seems this problem still exists. HE doesn't "activate" delegation on their NS before they are marked as authorative. However, e.g. doesn't give authority before the delegation isn't active. Thus, deadlock still exists.

Pages: [1] 2 3