TCP resets when using NAT network config.

[jglogan]

I think I'm seeing this issue, but I don't see any resolution, and was wondering if anyone's experienced this:

viewtopic.php?f=1&t=20579

I'm running an OS X 10.6.8 host with VBox 4.1.4, and an Ubuntu 10.04.3 guest. The guest is serving a Dojo web application that uses asynchronous loading of the JavaScript, and the JS application isn't compiled into a single file, so the browser on the client issues many concurrent requests to pull the JS files.

What I see is that with NAT network configuration, the webapp loads only some of the time. When it fails, I see that one or more HTTP requests show as "Aborted".

Pointing Wireshark at the problem shows that some of the TCP connections for HTTP requests are terminated with RST from the server.

When I use Firefox, things work about 50% of the time. When I use Chrome, the webapp almost never loads.

When I run the same guest with bridged network configuration, the webapp always loads successfully. This leads me to believe that there's something in the VBox network implementation that's averse to a large number of concurrent TCP requests being thrown at a guest. Does anyone have any ideas about this?

Thanks!

John

[jglogan]

It looks like 4.1.8 might address this problem. It resolves this bug:

https://www.virtualbox.org/ticket/8471

NAT Port Forwarding drops requests for LAMP services -> fixed in svn.

On both the Windows 32 and OS X 64 hosts, my guest OS (Win 32) running a LAMP web server on port 8081 drops requests randomly, sometimes causing web pages to not load CSS files or images. The problem was resolved when I switched from NAT to Bridged networking mode. It appears to be a bug with the port forwarding.

[jglogan]

4.1.8 definitely seems to help with my problem. With Firefox I'm seeing 100% successful loads on a site that pulls about 200-250 Dojo files both with Firebug enabled and disabled.

Chrome is more finicky; it seems to relish sending a ton of requests in parallel. It's still very hit-or-miss with JS debugging disabled, but we've also seen the same problem against a vSphere deployment of the same appliance. Enabling JS debug seems to make Chrome work hard enough that the page loads most of the time, which is a big improvement over pre-4.1.8.