Host cannot connect to guest using 2.1.2 host network interface

[Mike Sadd]

Just installed VirtualBox 2.1.2 Linux (64bit) on Ubuntu 8.10. Enabled the new host interface connection using the kernel module, with much easier set-up than 2.0.6.

Most connections work very well, in that the Guest can connect to all machines, and all other machines on the sub-net except the host can connect into the guest.

One issue is the connection from the host into the guest, similar to the issue in tickets #3017, #3056, #3080. Tried the patch mentioned there, but it appears to be applied already in 2.1.2 and in any case did not correct the behavior.

To illustrate issue, consider the result of tcdump while using nc to establish a tcp connection.

On the guest system (ip 192.168.0.14), executed:

nc -l 1234

On the host system (ip 192.168.0.17), executed:

nc 192.168.0.14 1234

No connection is established. The output of tcdump is:

# tcpdump -n -i eth1 port 1234
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
02:18:18.822102 IP 192.168.0.17.59399 > 192.168.0.14.search-agent: S 975096716:975096716(0) win 5840 <mss 1460,sackOK,timestamp 3008047 0,nop,wscale 7>
02:18:18.822102 IP 192.168.0.14.search-agent > 192.168.0.17.59399: S 306608439:306608439(0) ack 975096717 win 5792 <mss 1460,sackOK,timestamp 465234 3008047,nop,wscale 5>
02:18:18.822102 IP 192.168.0.17.59399 > 192.168.0.14.search-agent: . ack 1 win 46 <nop,nop,timestamp 3008047 465234>
02:18:18.824493 IP 192.168.0.14.search-agent > 192.168.0.17.59399: R 306608440:306608440(0) win 0
02:18:21.349578 IP 192.168.0.14.search-agent > 192.168.0.17.59399: R 0:0(0) win 0
02:18:21.349769 IP 70.116.89.60.9367 > 192.168.0.14.search-agent: R 0:0(0) win 0
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel

For comparison, if nc 192.168.0.14 is executed on a third host on the subnet, it works fine:

# tcpdump -n -i eth1 port 1234
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
02:19:20.942878 IP 192.168.0.3.dict-lookup > 192.168.0.14.search-agent: S 2628089796:2628089796(0) win 5840 <mss 1460,sackOK,timestamp 34219645 0,nop,wscale 2>
02:19:20.943098 IP 192.168.0.14.search-agent > 192.168.0.3.dict-lookup: S 1287294433:1287294433(0) ack 2628089797 win 5792 <mss 1460,sackOK,timestamp 527353 34219645,nop,wscale 5>
02:19:20.944878 IP 192.168.0.3.dict-lookup > 192.168.0.14.search-agent: . ack 1 win 1460 <nop,nop,timestamp 34219648 527353>
02:19:23.872159 IP 192.168.0.3.dict-lookup > 192.168.0.14.search-agent: F 1:1(0) ack 1 win 1460 <nop,nop,timestamp 34222577 527353>
02:19:23.872159 IP 192.168.0.14.search-agent > 192.168.0.3.dict-lookup: F 1:1(0) ack 2 win 181 <nop,nop,timestamp 530287 34222577>
02:19:23.872159 IP 192.168.0.3.dict-lookup > 192.168.0.14.search-agent: . ack 2 win 1460 <nop,nop,timestamp 34222579 530287>
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel

One difference may be in the third line of the output.

For host -> guest:
[...] . ack 1 win 46 <nop,nop,timestamp 3008047 465234>
For external ip->guest:
[...]  . ack 1 win 1460 <nop,nop,timestamp 34219648 527353>

[Aleksey Ilyushin]

The packet dump shows that the connection is closed by the listening side. Could that be a typo problem? Please make sure you do

nc -l -p 1234

in the guest.

[Mike Sadd]

Thanks for the help--that was a typo in the text of the message. The command on the guest was:

nc -l -p 1234

[Aleksey Ilyushin]

Right. Looking closely at the failed connection dump now I see that the "three-way" handshake actually took place, but the connection was torn down by the listening side almost immediately by sending a segment with RST bit set, meaning that the guest side of TCP connection detected some error. It would be interesting to see how it "looked" from guest's side. Could you run tcpdump in the guest?

[Mike Sadd]

I was not clear about that in my note--the output above was for tcpdump run on the guest system. Should I try it on the host?

The set-up that I was testing:

Host: ubuntu 8.10 (64 bit) acting as the client

Guest: fedora core 9 (32 bit) acting as the server

Thank you!

[Aleksey Ilyushin]

Interesting... Perhaps adding -vv option for nc on both sides may clarify a bit what is going on. The first three-packet sequence is an absolutely normal connection establishing exchange. I get an identical result on my setup (host=Ubuntu 8.10 64-bit, guest=Kubuntu 8.04 32-bit), including the window size of 46 (which is actually 46*7(wscale)), but connection is established normally. If nc -vv does not reveal anything useful could you try another guest to see if the behavior is the same?

[Aleksey Ilyushin]

By the way, are there any other adapters configured for the guest besides eth1? If yes what are their attachment types?

[Mike Sadd]

OK, at least I can isolate the cause--it appears to be related to using the wireless wlan0 interface as the host interface. If I attach the guest to a "tap0" interface created with tunctl, then I can connect to and from the guest and host as expected. When attached to wlan0, there is a problem when the host is the client and the guest is the server as above.

I know the limitations of the wireless adapters regarding IpV6 and IPX are mentioned in the manual, but is this behaviour related to that?

Using arp routing through a tap interface is perfectly fine for me, since it was also the solution in 2.0.6...

[Frank Mehnert]

Could you check if ​this change fixes your problem?

[Mike Sadd]

Thanks so much. I applied the patch and checked against the same guest/host combination in VirtualBox 2.2.2. I see the same behavior in which the connection is reset when connecting from host to guest. Other combinations (guest to host, or 3rd machine on the same subnet to guest) work with no issue.

An effective work-around is to connect through a tap interface on the host--in this case, no issue is seen. Since this work-around is little trouble to use, this issue is minor.