Windows Update failing using 6rd
-
Since upgrading to 2.4.1 (and 2.4.2) Windows Update (and Microsoft Store app Updates) does not work unless I go into the network adapter and turn off ipv6. After turning off ipv6 the updates work fine. When I turn ipv6 back on Windows update will keep working for a time (best estimates so far is about 12 hours) then it will stop working again. This happens to all computers in the network. If I take one of the computers somewhere else updates work perfectly fine so the problem is in my network. Here is a list of things I've tried:
-
Complete re-install of pfSense 2.4.2
-
Reduced the MTU
-
Removed all Traffic Shaping
-
Rebooted Modem
I'm using Cable Internet (Start.ca) and 6rd for ipv6. I've been using 6rd for a couple years with them and it has been solid. I've had a colleague who is using the same ISP enable 6rd and do some test and it is working for them. This leads me to believe that it is in pfSense. I have a second location that is using the same ISP and pfSense and they are having the same issue and it happened shortly after the upgrade to 2.4.1. All other sites that I regularly use that are IPv6 work perfectly fine.
This evening I'm going to try installing pfSense 2.3.5 as I know it was working when I was on the 2.3 branch.
Does anyone else have any ideas of what I should test/try next? I've been racking my brain on this one for a couple weeks now and could really use some more ideas. Testing has been a pain since it takes almost a day to know if I have fixed it.
Thank you,
-
-
I've now tried 2.3.5 and it didn't make a difference. I'm now pretty sure it isn't pfSense. Does anyone have any ideas for what to test next?
-
Hehe.
See my thread: https://social.technet.microsoft.com/Forums/windowsserver/en-US/16e7aa06-9b90-48f8-8370-76c2329b93a8/windows-update-ipv6?forum=ws2016 -
I saw your post and have tried reducing my MTU but even going to 1280 it didn't make any difference for me. Guess we just have to wait till Microsoft actually thinks this is a problem and addresses it. :(
-
Yeah it
s ms issue we can
t do nothing about it :( -
Here is a work around that seems to be working for me (so far - fingers crossed). Add a reject rule on your lan for any ipv6 packets with destination of: 2a01:111:f307:1790::f001:7a5 and 2a01:111:f335:1792::f001:7a5 this seems to cause it to switch to the ipv4 addresses. I just got these addresses doing a nslookup on sls.update.microsoft.com
Name: sls.update.microsoft.com.nsatc.net
Addresses: 2a01:111:f307:1790::f001:7a5
2a01:111:f335:1792::f001:7a5
13.68.87.175
13.78.230.134
52.229.171.202
13.74.179.117
Aliases: sls.update.microsoft.comThis might be a temporary fix until Microsoft gets around to doing something.
-
Incase anyone is following this it appears that Microsoft has fixed the issue.
-
Has anyone figured out a solution to this issue?
My windows machines and xbox have issues with windows update and the store when IPv6 is enabled.
Using a HE tunnel. -
Just to let anyone with the same problem know, for a few days now, the problem suddenly occured again.
2a01:111:f307:1790::f001:7a5 and 2a01:111:f335:1792::f001:7a5 exist and both have an AAAA record but they seem to not react on IPv6 connections.
I have 3 machines here which are not updating for a few days now except I disable IPv6 for a second, so that they can reach the update server by IPv4.
I'm now trying suggested solutions above.
Kind of a weird issue.Edit: Rejecting IPv6 packets to sls.update.microsoft.com servers seems to be a workaround.