Internet Not Working Through Router on Windows 7 and Vista
Back on an internet link behind a FreeBSD router, browsing suddenly stopped working on a Windows Vista laptop (and later the exact same issue appeared on Windows 7). Everything looked puzzling at first: nothing seemed to have changed on either the router or the laptop, ping worked, websites opened fine through a proxy, and nearby Windows XP machines worked normally – yet browsers on Vista and Windows 7 refused to load pages. I even restored Vista from its recovery image, and got the exact same result: ping worked, websites did not.
Internet not working through a router on Windows 7 and Windows Vista – real-world root cause and step-by-step troubleshooting
At first, I simply routed the few Windows 7 and Vista clients through another gateway, but eventually I sat down to track down the real culprit in the router’s NAT and firewall configuration. Below is both the exact FreeBSD ipfw/NAT fix and a complete checklist for home and office routers when Windows 7 or Vista shows “No internet access” (yellow exclamation triangle) or fails to load websites while ping still succeeds.
Why Ping Works While Websites Fail: FreeBSD ipfw and Ports 49152–65535
Since ping worked, proxies loaded pages normally, and Windows XP on the same network had no trouble at all, the issue clearly lived in NAT or the router firewall rather than inside Windows itself. Generic search tips focused on Windows tweaks and changed nothing.
To catch the problem on the FreeBSD router, I cleared the ipfw rule counters and watched which rules triggered the moment a Windows 7 machine tried to open a webpage. At first I suspected a deny rule, but temporarily removing the block rules did not help. Then I spotted traffic hitting an old passive FTP rule that sat further down in the text file, yet carried an earlier rule number 00095 and therefore ran before NAT:
00095 41 1968 allow tcp from any to <IP> dst-port 49152-65535 via nve0
Why did this break Windows Vista and Windows 7 while leaving Windows XP unaffected? The answer is the default ephemeral (dynamic) outbound port range:
- Windows XP and Server 2003: used ports
1025–5000by default for outbound TCP connections, so return packets never touched the FTP rule. - Windows Vista and Windows 7: switched to the IANA dynamic port range
49152–65535. When reply packets from web servers returned to the router’s WAN IP on those ports, rule00095matched before NAT and swallowed the traffic before it could reach the client.
Removing that obsolete FTP rule (or moving NAT ahead of it) restored web browsing on Windows 7 and Vista immediately. You can check the active dynamic TCP port range on Windows 7 or Vista with:
netsh int ipv4 show dynamicport tcp
What to Check on Any Router When Windows 7 or Vista Has “No Internet Access”
If you are behind a regular home or office router (TP-Link, Asus, D-Link, MikroTik) and other devices work properly while Windows 7 or Vista shows a yellow triangle or fails to load pages, walk through the checks below. They cover TCP Auto-Tuning, DNS/DHCP failures, IP conflicts, and MTU mismatches.
1. Test Connectivity by IP Address vs. Domain Name
Open Command Prompt (cmd) and test both a raw IP and a domain name:
ping 8.8.8.8 ping google.com
If 8.8.8.8 responds while domain names fail to resolve, the culprit is DNS (a broken DNS relay also explains cases where only a few cached or local websites open). If even IP pings fail, check DHCP, static IP conflicts, gateway settings, or firewall rules.
2. Verify Router DHCP and Rule Out Static IP Conflicts
Inspect your current IP address, subnet mask, default gateway, and DNS servers:
ipconfig /all
Check that Windows has not fallen back to an APIPA address (169.254.x.x) and that the default gateway matches your router’s LAN IP (commonly 192.168.1.1 or 192.168.0.1). To renew the DHCP lease and clear the local DNS cache, run an elevated Command Prompt and execute:
ipconfig /release ipconfig /renew ipconfig /flushdns
If another device on the network holds a conflicting static IP inside the DHCP pool, traffic stalls or drops. To verify your adapter in the GUI, press Win+R, run ncpa.cpl, open Properties on the active connection, select Internet Protocol Version 4 (TCP/IPv4), and switch both IP and DNS to automatic. On the router itself, confirm that the DHCP server is enabled and its address pool is not exhausted.
3. Switch to Reliable Public DNS Servers (8.8.8.8 and 1.1.1.1)
When an ISP or router DNS forwarder malfunctions, browsers stall on “Resolving host” or only open a handful of websites. In the GUI (ncpa.cpl → Adapter Properties → TCP/IPv4), set the preferred DNS to 8.8.8.8 and alternate DNS to 1.1.1.1 (or 8.8.4.4).
You can also apply this in an elevated PowerShell window without hardcoding an adapter name (querying Win32_NetworkAdapter works natively on Windows Vista and Windows 7 without requiring Windows 8+ modules):
$nic = Get-WmiObject Win32_NetworkAdapter ` -Filter "NetConnectionStatus=2 AND PhysicalAdapter=True" | Select-Object -First 1 -ExpandProperty NetConnectionID netsh interface ipv4 set dns name="$nic" ` static 8.8.8.8 primary netsh interface ipv4 add dns name="$nic" 1.1.1.1 index=2
To revert DNS back to automatic (DHCP) later:
netsh interface ipv4 set dns name="$nic" dhcp
4. Disable TCP Auto-Tuning and Heuristics
Windows Vista and Windows 7 introduced Receive Window Auto-Tuning and TCP heuristics (RFC 1323 window scaling). Many older routers choke on scaled TCP windows – ping succeeds without packet loss, while HTTP/HTTPS pages hang indefinitely.
First inspect the current TCP settings in an elevated Command Prompt:
netsh interface tcp show global netsh interface tcp show heuristics
Disable heuristics and TCP Auto-Tuning to test compatibility:
netsh interface tcp set heuristics disabled netsh interface tcp set global autotuninglevel=disabled
If pages start loading immediately (sometimes after a reboot), the router was mishandling window scaling. If nothing changes, restore the default setting:
netsh interface tcp set global autotuninglevel=normal
5. Fix Router WAN MTU Mismatches (PPPoE / L2TP)
If the router connects over PPPoE (typical MTU 1492) or L2TP (1460) while Windows sends 1500-byte frames and ICMP fragmentation messages are dropped along the path, small pings pass while websites stall. Find the largest unfragmented payload with:
ping 8.8.8.8 -f -l 1472 ping 8.8.8.8 -f -l 1464
Add 28 bytes for IP and ICMP headers to the largest payload that succeeds without “Packet needs to be fragmented” (for example, 1464 + 28 = 1492). Ideally, set this MTU on the router’s WAN settings page; to adjust it on the active Windows interface in an elevated PowerShell prompt, run:
netsh interface ipv4 set subinterface "$nic" ` mtu=1492 store=persistent
6. Reset Winsock and Restart the Network Adapter Driver
Corrupted LSP/Winsock entries from failed updates or security software can block browsers while leaving ICMP ping intact. In an elevated Command Prompt, reset the network stack and reboot:
netsh winsock reset netsh int ip reset
It is also worth resetting the adapter driver: press Win+R, open devmgmt.msc, expand Network adapters, disable and re-enable the card (or uninstall the device without deleting driver files and click “Scan for hardware changes”). On older routers, also check MAC address filtering and test unchecking Internet Protocol Version 6 (TCP/IPv6) inside ncpa.cpl.
49152–65535 and test disabling TCP Auto-Tuning via netsh first.