NAT lost RST packet on Windows host - and then silently drops packets

[Morris]

It appears that the VirtualBox NAT is somehow dropping or mishandling TCP packets in some circumstances. After the RST packet is not passed to the client for a connection, then the NAT seems to drop packets from the guest for that connection (causing timeouts, rather than immediate failure).

To repeat:

Set up a windows host and a windows guest, with the guest configured to use a NAT network.

First lets see what happens normally buy navigating to ​http://appserver1.timefiler.com/vbox_nat_fail.html using IE on the guest, click the "retry after 3 minutes" and see that you get a "Fetched 2" message at the 3 minute timeout.

To see it fail, open ​http://appserver1.timefiler.com/vbox_nat_fail.html in Chrome on the guest, click the "retry after 3 minutes" and at the 3 minute mark the response div goes blank because no reply occurs.

Notes:

1. I could only repeat using a windows host (problem found on Windows 7 host, Windows host, but no problem when using an Ubuntu 8.04 LTS host).

2. I could repeat the problem on different guests (tested with Windows XP guest, Windows 7 guest, Windows 8 guest, Debian guest).

3. The problem only occurs when using Chrome or Chromium browser on the guest (Other browsers work fine because they don't seem to cause the RST packet from the web server - I presume due to different keep-alive implementations such as timeouts).

4. Don't use an http proxy (different keep-alive implementation).

5. I repeated this problem on two different internet connections, on my work network using a wired LAN, and secondly on my mobile network using USB tethering. (And only one connection was active at one time, the other was disconnected).

This looks like a VirtualBox NAT problem to me, not a problem in Chrome.

I have included two files showing the relevant extract of the virtualbox nictrace from the guest "swan" ( file swan-nictrace-on-weka.pcap - IP address of guest on vbox subnet is 10.0.3.15 ) and a wireshark trace on the host "weka" ( file wireshark-on-weka.pcap - IP address of the host is 192.168.42.8 ). appserver1.timefiler.com is on 202.124.97.47

The important packets are:

A) Packet 28 on the host in wireshark-on-weka.pcap - the RST packet is not passed into the guest.

B) Packet 15 on the guest in swan-nictrace-on-weka.pcap - the HTTP packet of length 1031 to 202.124.97.47 never shows up in the host log.

C) Packet 16 on the guest in swan-nictrace-on-weka.pcap - where does the TCP ACK=1954 message come from? In the host log it can be seen that it doesn't come from 202.124.97.47.

In the logs you can see I manually send a ping to 8.8.4.4 shortly before and shortly after a successful HTTP message, and a ping to 8.8.8.8 shortly after the failed HTTP message.

[Morris]

nictrace using virtualbox of guest LAN

[Morris]

trace using wireshark on the host (weka)

[Morris]

vbox.log for the swan guest

[Morris]

Probably not relevant, but the symptoms on a Windows 8 guest are different from the symptoms on Linux Debian, Windows XP, or Windows 7. Also note that the problem also occurs on a Windows 8 host on another laptop in the office.

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.