Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Roughly 50% of all HTTP request are being refused/timing out when trying to access the guest OS from the host OS via NAT. Requests being called via http://localhost:8001

Below are some details:

Host OS: Mac OS X Lion (10.7.2) - 64 bit
Guest OS: CentOS 5.7 2.6.18-274.el5 - 64 Bit
VirtualBox: 4.1.6.r74713 - Network Adapter Type: NAT

Port forwarding is setup and running:

$ VBoxManage showvminfo thevm |grep "NIC 1"
NIC 1:           MAC: 0800272C2273, Attachment: NAT, Cable connected: on, Trace: off (file: none), Type: 82540EM, Reported speed: 0 Mbps, Boot priority: 0, Promisc Policy: deny
NIC 1 Settings:  MTU: 0, Socket (send: 64, receive: 64), TCP Window (send:64, receive: 64)
NIC 1 Rule(0):   name = http, protocol = tcp, host ip = , host port = 8001, guest ip = , guest port = 80
NIC 1 Rule(3):   name = ssh, protocol = tcp, host ip = , host port = 2222, guest ip = , guest port = 22

From the Host OS:

$ netstat -nl |grep tcp |grep 127.0.0.1
tcp4       0      0  127.0.0.1.8001         127.0.0.1.59056        ESTABLISHED
tcp4       0      0  127.0.0.1.8001         127.0.0.1.59055        ESTABLISHED
tcp4       0      0  127.0.0.1.59056        127.0.0.1.8001         ESTABLISHED
tcp4       0      0  127.0.0.1.8001         127.0.0.1.59054        ESTABLISHED
tcp4       0      0  127.0.0.1.59055        127.0.0.1.8001         ESTABLISHED
tcp4       0      0  127.0.0.1.59054        127.0.0.1.8001         ESTABLISHED
tcp4       0      0  127.0.0.1.2222         127.0.0.1.58891        ESTABLISHED
tcp4       0      0  127.0.0.1.58891        127.0.0.1.2222         ESTABLISHED
tcp4       0      0  127.0.0.1.5037         127.0.0.1.54240        ESTABLISHED
tcp4       0      0  127.0.0.1.54240        127.0.0.1.5037         ESTABLISHED

Also from Host OS:

$ netstat -nl |grep tcp |grep 127.0.0.1
tcp4       0      0  127.0.0.1.56778        127.0.0.2.80           SYN_SENT   
tcp4       0      0  127.0.0.1.56777        127.0.0.2.80           SYN_SENT   
tcp4       0      0  127.0.0.1.56776        127.0.0.2.80           SYN_SENT   
tcp4       0      0  127.0.0.1.2222         127.0.0.1.55086        ESTABLISHED
tcp4       0      0  127.0.0.1.55086        127.0.0.1.2222         ESTABLISHED
tcp4       0      0  127.0.0.1.2222         127.0.0.1.54727        ESTABLISHED
tcp4       0      0  127.0.0.1.54727        127.0.0.1.2222         ESTABLISHED
tcp4       0      0  127.0.0.1.5037         127.0.0.1.54240        ESTABLISHED
tcp4       0      0  127.0.0.1.54240        127.0.0.1.5037         ESTABLISHED

(the destination fo 127.0.0.2 looks a little off to me...)

From Guest OS:

$ netstat -nl |grep tcp
tcp        0      0 0.0.0.0:110                 0.0.0.0:*                   LISTEN      
tcp        0      0 0.0.0.0:143                 0.0.0.0:*                   LISTEN      
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      
tcp        0      0 0.0.0.0:80                  0.0.0.0:*                   LISTEN      
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      
tcp        0      0 0.0.0.0:443                 0.0.0.0:*                   LISTEN      
tcp        0      0 0.0.0.0:670                 0.0.0.0:*                   LISTEN 

SSH works fine - no issues there at all.
My google-fu is failing me hard on this one. This VM was initially created on a Win7 box, exported, and then imported onto OS X Lion. It works fine on Win7 (and continues to do so for devs using Windows boxes).

iptables are disabled - as well as SELinux.

Here is a tcpdump from Guest OS:

$tcpdump -v |grep http
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:19:39.304055 IP (tos 0x0, ttl  64, id 47318, offset 0, flags [none], proto: TCP (6), length: 44) 10.0.2.2.58975 > 10.0.2.15.http: S, cksum 0x0bf8 (correct), 225280001:225280001(0) win 65535 <mss 1460>
15:19:39.304081 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: TCP (6), length: 44) 10.0.2.15.http > 10.0.2.2.58975: S, cksum 0xa1a1 (correct), 1043076425:1043076425(0) ack 225280002 win 5840 <mss 1460>
15:19:39.304120 IP (tos 0x0, ttl  64, id 47319, offset 0, flags [none], proto: TCP (6), length: 44) 10.0.2.2.58976 > 10.0.2.15.http: S, cksum 0x11f6 (correct), 225344001:225344001(0) win 65535 <mss 1460>
15:19:39.304126 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: TCP (6), length: 44) 10.0.2.15.http > 10.0.2.2.58976: S, cksum 0xb6b7 (correct), 1039140461:1039140461(0) ack 225344002 win 5840 <mss 1460>
15:19:39.304154 IP (tos 0x0, ttl  64, id 47320, offset 0, flags [none], proto: TCP (6), length: 40) 10.0.2.2.58975 > 10.0.2.15.http: ., cksum 0xd02e (correct), ack 1 win 65535
15:19:39.304258 IP (tos 0x0, ttl  64, id 47321, offset 0, flags [none], proto: TCP (6), length: 44) 10.0.2.2.58978 > 10.0.2.15.http: S, cksum 0x17f3 (correct), 225408001:225408001(0) win 65535 <mss 1460>
15:19:39.304264 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: TCP (6), length: 44) 10.0.2.15.http > 10.0.2.2.58978: S, cksum 0x1ffb (correct), 1041146632:1041146632(0) ack 225408002 win 5840 <mss 1460>
15:19:39.304291 IP (tos 0x0, ttl  64, id 47322, offset 0, flags [none], proto: TCP (6), length: 40) 10.0.2.2.58976 > 10.0.2.15.http: ., cksum 0xe544 (correct), ack 1 win 65535
15:19:39.304294 IP (tos 0x0, ttl  64, id 47323, offset 0, flags [none], proto: TCP (6), length: 44) 10.0.2.2.58979 > 10.0.2.15.http: S, cksum 0x1df1 (correct), 225472001:225472001(0) win 65535 <mss 1460>  

Any help is greatly appreciated.

share|improve this question
up vote 1 down vote accepted

A user in the #vbox IRC channel on freenode pointed me to: Virtualbox bug report. That solved the issue. The solution is as follows:

Depending on your guest VM's configuration execute one of the following commands:

# VBoxManage set extradata <vmname> \
"VBoxInternal/Devices/e1000/0/LUN#0/Config/SoMaxConnection" 10

Or

# VBoxManage set extradata <vmname> \
"VBoxInternal/Devices/pcnet/0/LUN#0/Config/SoMaxConnection" 10
share|improve this answer
    
So, what exactly you did to solve the problem? – Sachin Divekar Nov 28 '11 at 22:05
    
Ran this command from the Bug report linked above: VBoxManage set extradata <vmname> "VBoxInternal/Devices/e1000/0/LUN#0/Config/SoMaxConnection" 10 – mote Nov 29 '11 at 16:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .