Problem in network Windows 11 24h2

The Connection icon changed to showing a connection, but still no

internet.

So, there's nothing wrong between your device and the "LAN" side of cable-modem. If you use the IPCONFIG command, the output should be similar to:

Ethernet adapter Local Area Connection:

IPv4 Address. . . . . . . . . . . : 10.0.0.133

Default Gateway . . . . . . . . . : 10.0.0.1

DNS Servers . . . . . . . . . . . :

                                  **64.59.160.13** 

                                  **64.59.161.68**

showing that the cable-modem is on your LAN, using "10.0.0.1", and a DHCP-server has assigned "10.0.0.133" to your device, and showing the DNS-servers your device will query.

Logging-in to the cable-modem, I see:

Internet:Active

WAN IP Address (IPv4):70.66.129.43

WAN Default Gateway Address (IPv4):70.66.128.1

Primary DNS Server (IPv4):64.59.160.13

Secondary DNS Server (IPv4):64.59.161.68

showing that the cable-modem has a "public" IP-address, and communicates with the ISP's router at "70.66.128.1", and uses the same DNS-servers as my device.

Have you tried a power-off/power-on of the cable-modem, to get it to completely "refresh" its connection to your ISP?

We are getting DHCP on both Ethernet and WiFi without issue.

That's perfect communication between your device and the cable-modem.

I am unable to get to anything through DNS

What IP-address(es) do show (as above) for your device, and for the "WAN" side of the cable-modem?

I can navigate via IP and ping 8.8.8.8 outside of the network.

$ ping -4 dns.google

Pinging dns.google [8.8.8.8] with 32 bytes of data:

Reply from 8.8.8.8: bytes=32 time=14ms TTL=119

Reply from 8.8.8.8: bytes=32 time=11ms TTL=119

Reply from 8.8.8.8: bytes=32 time=11ms TTL=119

Reply from 8.8.8.8: bytes=32 time=10ms TTL=119

**Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)**

Note that my DNS-servers resolved the name "dns.google" to the 8.8.8.8 IP-address. Your output may be different, namely "unable to resolve ...", or something like:

Pinging 8.8.8.9 with 32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

**Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)**

when I PING'd a "nearby" IP-address.

Whatever is happening appears to be DNS related,

Agree, but where is the issue? Maybe, wrong IP-addresses inside the cable-modem for the DNS-servers?

Setting a static IP also did not resolve the issue

nor changing the DNS manually.

That is to be expected, since the problem seems to be "elsewhere", because there is nothing wrong on your device.

Somehow, the responses from the DNS-servers are not reaching your device ("filtering" inside the cable-modem), or Windows on your device is "blocking" those DNS-responses.

Do you have any "Internet Security" packages that might be blocking the responses, such as "Norton 360" or "McAfee"?

Do either of those apps write "log-files" that record each "blocking" action?

Do you (or a friend) have another Windows computer, that you can connect to the cable-modem? If so, does that system function correctly?

Thank you Melvin Klassen for the detailed response. As the origin of this thread from months ago when I first troubleshoot these issues related to Windows update 24h2. This issue is 100% related to the device and something changing within the update. I now have a few computers in our enterprise network running Windows 11 that experience this issue after the update is installed. Today I took a different a route and attempted multiple of the "solutions" found within this thread to no avail.

The issue is 100% related to the updated as rolling back once again resolved all the issues. The issue is 100% related to the update, but does not seem to effect all devices, for instance I am on a similar model Dell Precision laptop running a similar dock as the computer with the issue today. The issue affected two physical ethernet NIC's as well as the WiFi NIC.

When I have more time I will troubleshoot the issue again and see what new things I can chase down while Microsoft turns a blind eye!

For anyone else who experiences the issue attempt to ping or remote desktop into a local computer by IP address. Also attempt to ping an outside source by IP address 8.8.8.8 for instance. If this works it will help narrow down whatever is causing the issue. I was successful in this today proving I have network, but DNS is not resolving correctly or being blocked by some change 24h2 is making.

In this thread, one person suggested to disable IPv6 on their computer's networking configuration. Did you try that?

Use IPCONFIG /ALL

and examine whether a fake DNS server (which is not advertized by your DHCP server) has been inserted on top of the list of DNS servers.

This DNS server having an IPV6 address does not resolve correctly, especially your internal hosts.

Also your local domain suffix is not taken into account.

If I disable IPV6 at the interface level, the networking seems to be alright.

As I had also problems with the RDP client, I decided to revert to 23H2 (remember: this is possible only for 10 days after the upgrade)

I have had the same issue as many have mentioned. Updated to 24H2 and bang my network sharing no longer functions. I am running a private network with shared access to Everyone connected to my network. I use this network as a backup solution between my house and my computer repair shop. Hopefully EVERYONE that is having problems with 24H2 killing their home network sharing will read this fix. This worked for me on all 3 of my networked computers. Two of my computers are running Windows 11 Pro 24H2 and one is running Windows 11 Home 24H2. Perform the following steps:

1.   In the seach box immediately to the right of the Start button type gpedit.msc, you will see the Microsoft Common Console Document; click that:

1. In the left pane under Local Computer Policy, navigate to Computer Configuration\Administrative Templates\Network\Lanman Workstation.
2. Open Enable insecure guest logons, select Enabled, then select OK.
3. Restarting computers on the network is likely not necessary, but I did so just as a Nyaaaaa because by this time I was aggravated. This immediately made my networked computers visible and accessible. I didn't have issues with WiFi connectivity only the loss of my network sharing visibility and access. I hope this helps!