When VirtualBox NAT resolves DNS but blocks every browser session

VirtualBox NAT networks are supposed to be the boring default. You install a guest OS, leave the network mode on NAT, and the guest reaches the internet through the host’s interface. Most of the time that works. The bad day is when DNS resolves cleanly inside the guest, ping to an external hostname gets a reply, and yet every browser request times out. No proxy, no firewall rules, no exotic setup. Just a guest that can look up names and reach IPs but cannot actually fetch a single web page.

Two forum threads describe this exact scenario on VirtualBox 5.x and 7.x with Windows hosts, both using the default Intel PRO/1000 MT Desktop adapter in NAT mode. The same symptoms appear in posts going back to 2014, which is a hint that the cause is structural rather than version-specific.

What the symptoms are telling you

If your guest can resolve a hostname with dig example.com or nslookup example.com and gets a real IP back, then your DNS path is functional. If ping 8.8.8.8 succeeds, your routing path is functional. If curl http://example.com then hangs forever without a TCP reset, the problem is between layer 4 (TCP handshake) and layer 7 (HTTP request), which is the narrow band that VirtualBox NAT normally handles invisibly.

The narrow band is where MTU and TCP segmentation live. The most common cause of this exact symptom is MTU mismatch (a Maximum Transmission Unit mismatch, where the host’s interface accepts 1500-byte frames but the guest’s NAT path can only carry smaller ones). The guest sends a 1500-byte SYN packet, the upstream path silently drops or fragments it, and the browser sits there waiting for a response that will never arrive.

Quick triage checklist to isolate where the breakdown is:

• DNS resolves from the guest. dig example.com or nslookup example.com should return a real IP. If this fails, the problem is upstream of NAT entirely, not inside it.
• The guest can ping an external IP. ping 8.8.8.8 from inside the guest. If this fails, routing inside VirtualBox is broken, which is a different bug class.
• The guest can ping a hostname but cannot fetch a URL. This is the symptom you are here for, and the next step is an MTU probe.
• The same URL fetches from the host. If it works on the host and not the guest, the issue is guest-side or VirtualBox NAT, not the upstream network.

The MTU probe from the guest is the next move once DNS and ping both work and browsing still hangs:

• Run an MTU probe from the guest. ping -M do -s 1472 example.com will tell you whether the largest unfragmented packet the path can carry is closer to 1500 (full Ethernet) or 1464 (PPPoE or some VPN overlay). If the -s 1472 ping fails, drop the value by 8 and try again until it works. The highest value that succeeds is your path MTU minus 28.
• Test from the host side too. The same ping -M do -s 1472 from the host against the same target confirms whether the host’s path is fine and the guest’s NAT path is the bottleneck. Most of the time the host path is fine, which isolates the issue to the VirtualBox NAT engine.
• Check for VPN or virtual adapter interference on the host. GlobalProtect, Cisco AnyConnect, and a dozen other corporate VPN clients install virtual adapters that show up to VirtualBox as a separate interface. If your NAT adapter is bound to one of those instead of the physical NIC (network interface card), the MTU drops and the NAT engine silently fragments.

The VirtualBox NAT engine, briefly

VirtualBox’s NAT mode is not a bridge. It is a userspace NAT engine that runs as part of the VBoxSVC process on the host. Each guest network interface in NAT mode is connected to an internal switch inside VirtualBox, and the engine translates addresses between the guest’s RFC 1918 IP (a private address from the 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 ranges) and the host’s external IP. The engine does its own segmentation handling for packets larger than the path MTU, and that handling has been the source of intermittent bugs across versions.

The MTU handling specifically has a known limitation. If the engine decides the path MTU is too small for a guest packet, it should send an ICMP “fragmentation needed” message back to the guest so the guest can retry smaller. In some VirtualBox versions on Windows hosts, the engine does not send the ICMP correctly, and the guest keeps retransmitting the same large packet until it gives up. The fix on the guest is to lower the MTU on the guest interface, which forces the guest to send small enough packets that the engine’s segmentation never has to fire.

How to set the guest MTU down to a known-good value:

• Linux guest, persistent. Edit /etc/NetworkManager/system-connections/*.nmconnection and add mtu=1400 under the [ipv4] section, then nmcli connection reload. This survives reboots and is the cleanest fix if you do not want to chase the VirtualBox bug.
• Linux guest, quick test. ip link set eth0 mtu 1400 (replace eth0 with the actual interface name from ip link) sets the MTU for the current session. Reload any page that was hanging. If it loads, MTU was the issue.
• Windows guest. netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent does the same on a Windows guest. The interface name has to match what shows up in netsh interface ipv4 show subinterfaces.

When MTU is not the issue

If the MTU probe passes at 1472 from the guest, the problem is elsewhere. Two other things cause the exact same symptom:

1. A stale VirtualBox host-only network. If a previous bridged-network guest left a host-only adapter in a half-removed state, the NAT engine can pick it up as its upstream interface. Disable unused host-only networks under File > Host Network Manager in the VirtualBox GUI, then restart the guest.
2. Windows Firewall blocking outbound traffic from VBoxSVC. Windows Firewall can block outbound connections from C:\Program Files\Oracle\VirtualBox\VBoxSVC.exe if a third-party security tool has tagged it. Add an explicit outbound allow rule for VBoxSVC and the symptom clears.

Both of these are rarer than MTU mismatch, but the symptom is indistinguishable from the MTU case unless you run the probe.

Trade-offs

Lowering the guest MTU is a workaround, not a fix. The throughput on the guest drops by a few percent because every packet now carries more headers relative to payload. For a desktop VM that browses the web, the cost is invisible. For a VM that copies large files between guest and host over its NAT interface, the cost is real.

The VirtualBox alternative for the same workload is bridged networking. With bridged mode, the guest gets its own IP on the host’s LAN (local area network) and the host’s MTU applies directly. No NAT engine involved, no segmentation mismatch. The cost is that bridged mode requires a DHCP server on the LAN and exposes the guest to the network, which is fine on a home network and not fine on a corporate one with network access control.

Another option is host-only networking with an outbound NAT at the host firewall, which is what vagrant up does by default on most boxes. It is reproducible, well-tested, and easier to debug than VirtualBox’s native NAT. The cost is that you now depend on the host firewall rules, which is a maintenance surface.

If you only have one guest and you trust the host’s MTU path, the MTU drop on the guest is the smallest change. If you have many guests or you want predictable networking, bridged mode or a host-only network with explicit NAT is worth the extra setup.

Bottom line

If your guest can resolve DNS but cannot browse, run ping -M do -s 1472 example.com from inside the guest before you do anything else. That single command tells you whether MTU mismatch is the cause in under five seconds. If the probe fails, drop the MTU on the guest interface to 1400 and reload the page. If the probe passes, look at host-only network leftovers and Windows Firewall rules before chasing deeper theories. The VirtualBox NAT engine has had versions where each of these was the bug, and there is no clean way to tell them apart from the guest side other than by elimination.