My Windows laptop has a very specific connectivity problem: IPv4 stops working when I connect to my condominium's Wi-Fi, while IPv6 continues to work. The same laptop has full IPv4 and IPv6 connectivity through my phone's hotspot, and my phone works normally on the condominium network. This setup was also working a few days ago.
On the condo Wi-Fi, the laptop receives an address such as 192.168.50.124, with a /24 subnet and gateway 192.168.50.1. I can ping the gateway over IPv4, but traffic beyond it fails. Pinging 1.1.1.1 or 8.8.8.8 fails completely, Test-NetConnection to 1.1.1.1 on TCP port 443 fails, and curl forced to IPv4 cannot connect. DNS resolution works, and IPv6 tests such as pinging google.com succeed.
I have already tried different browsers, a Windows network reset, reinstalling the Wi-Fi driver, netcfg -d, flushing DNS, changing DNS servers, manually configuring IPv4, checking adapter bindings, disabling the proxy, confirming there is no VPN, and reviewing firewall settings. I also changed the randomized MAC address and released/renewed DHCP; the laptop received a different address, 192.168.50.110, but the problem remained. A trace to 1.1.1.1 eventually reports that 192.168.50.1 cannot reach the destination network.
DISM reported that the component store was repairable and later caused a blue-screen crash during repair. SFC found and repaired corrupted files, but IPv4 connectivity is still broken.
Could this be a device-specific issue in the condominium network, such as an ACL, NAT state, routing problem, or MAC-based policy? What tests would best separate a Windows or laptop problem from an issue with the condominium network or ISP?
4 Answers
The BSOD and repaired system files are worth investigating separately, but they do not automatically explain a failure that occurs only on one Wi-Fi network. Look for minidump files in C:WindowsMinidump and analyze the crash cause, while avoiding more disruptive resets until the network behavior is isolated. Also ask the condo network administrator whether your device needs to be registered or reauthorized and whether they can check the gateway’s DHCP, NAT, firewall, and client-specific logs.
The results point away from DNS and toward the condo gateway or its upstream IPv4 path. Reaching 192.168.50.1 only proves the local Wi-Fi link works; it does not prove that the gateway is forwarding your IPv4 traffic. Since the laptop works on a hotspot and changing both its DHCP address and randomized MAC did not help, a simple block tied to one address is less likely. A captive-portal or device-registration issue, a per-client IPv4 policy, or a broken NAT/ACL entry could still be involved. The trace showing 192.168.50.1 reporting the unreachable network is especially useful evidence to give the network administrator.
Boot the laptop from a Linux live USB and test the same condo Wi-Fi there. If IPv4 fails in Linux too, that strongly implicates the condo network, the access point, or the laptop’s interaction with that network rather than Windows. Check whether Linux receives an address and default route, then test the gateway, 1.1.1.1, and an IPv4-only website. If Linux works normally, focus on Windows drivers, filtering components, or the system configuration.
Make sure the network’s sign-in or captive portal has actually completed for this laptop. Some managed Wi-Fi systems allow IPv6 or local gateway access before authentication but restrict IPv4 Internet traffic. Forgetting and reconnecting to the network, opening a plain HTTP page to trigger the portal, and checking whether other residents have the same IPv4 failure can help distinguish an account/device authorization issue from a wider outage.
I already tried a new randomized MAC address and a DHCP release/renew. The laptop got 192.168.50.110 instead of 192.168.50.124, but IPv4 still could not reach the Internet. I’ll use the gateway trace and a Linux live USB test to narrow it down further.