NAT does not seem to properly set the source ip of some incoming packets

[Jason Desai]

Since upgrading to VirtualBox 3, I've been having problems with NAT. Things worked fine in 2.2.4. Specifically, it appears that the source address of packets are not being NATed properly. Some of them appear to come from 10.0.2.2 instead of from their real source address. This can cause applications drop packets, making it look like there is latency, or packet loss.

I will attach a wireshark capture from the guest when it was pinging www.virtualbox.org. Notice that some of the responses come from 10.0.2.2, and not from 208.73.210.26. This causes the guest to wait until it times out for the ping response, and then next echo request is sent out after the timeout (5 seconds in this case).

I've seen this happen with udp packets as well, causing issues for VPN types of applications.

Reverting to 2.2.4 or changing to bridged networking fixes the issue.

[Jason Desai]

Wireshark capture of a ping of www.virtualbox.org, showing wrong source address on replies.

[Jason Desai]

Forgot to mention that the host is Ubuntu Jaunty (64-bit) and the guest was 32-bit XP Pro.

[vasily Levchenko]

Thank you for information. Could you please add Log file also?

[Jason Desai]

Log File

[Jason Desai]

Is this the log file you're looking for? Let me know if you need anything else.

[vasily Levchenko]

Replying to jasetheace:

Is this the log file you're looking for? Let me know if you need anything else.

thank you.

[Georg Glaser]

jasetheace, can you confirm that the problem has been solved?

I'm asking because I also have packet loss problems since upgrading to VirtualBox 3. Today I upgraded to version 3.0.4 and still have those problems. I also upgraded the VBoxLinuxAdditions but without improvement.

fuzzie@xxxxx:~$ ping www.virtualbox.org
PING www.virtualbox.org (88.198.19.108) 56(84) bytes of data.
64 bytes from virtualbox.org (88.198.19.108): icmp_seq=1 ttl=50 time=47.3 ms
64 bytes from virtualbox.org (88.198.19.108): icmp_seq=11 ttl=50 time=20.2 ms
64 bytes from virtualbox.org (88.198.19.108): icmp_seq=21 ttl=50 time=57.7 ms
64 bytes from virtualbox.org (88.198.19.108): icmp_seq=32 ttl=50 time=19.4 ms

--- www.virtualbox.org ping statistics ---
32 packets transmitted, 4 received, 87% packet loss, time 35204ms
rtt min/avg/max/mdev = 19.441/36.194/57.794/16.779 ms

[vasily Levchenko]

Replying to fuzzie: Could you please attach the log?

[vasily Levchenko]

Thanks fuzzie, you've Windows build which uses ICMP API detecting not whole ICMP traffic that is the reason of behavior you've seen. to make double check you may collect ​pcap files to see problematic packets which was detected by reporter initially. Some portion of the ICMP traffic has been come from "router" (10.0.2.2)? If you see this then problem still persists if no it's problem with ICMP API (which you can describe in separate defect).

[Jason Desai]

Replying to fuzzie:

jasetheace, can you confirm that the problem has been solved?

I can confirm that the issue itself has been fixed. I do see some latency issues when using NAT still, but specifically the wrong source address on incoming packets has been fixed, from that I have seen.

[vasily Levchenko]

Replying to fuzzie:

Replying to fuzzie:

jasetheace, can you confirm that the problem has been solved?

I can confirm that the issue itself has been fixed. I do see some latency issues when using NAT still, but specifically the wrong source address on incoming packets has been fixed, from that I have seen.

Is this only traffic you've been able collect? there is only one ethernet packet. I mean ping.2.pcap file

[Georg Glaser]

Hi, sorry I did not check the pcap file fist (because I did not know how), I also don't know why there was only one packet inside because I did the same thing as now.

I created a new pcap file and checked it with WireShark. According to the pcap file there should be about 47 ping replys, only a few ping requests did not get a reply.

But as you can see in the attached screenshot actually the guest operating system (Ubuntu 32-bit) only received 10 ping replys.

It seems that there is a packet loss problem. According to the pcap file some ping requests (frame 85 to 96) did not receive a reply at all but further not all ping replys that came through the network where recognized by the guest os.

Any clues?

[vasily Levchenko]

Replying to fuzzie:

Any clues?

Fuzzie, clue I've provided at first my reply ;). ICMP test on Windows looks problematic if replies comes from 10.0.2.2 instead of real source.

[Georg Glaser]

ok, so please close this ticket again :)

[baturix]

I am having this issue with 3.0.6 and 3.0.4.

I run a LUM license server in a windows guest. It uses an UDP protocol and it is not working because the NAT engine seems to be changing the source IP with the IP of the hosts (in the virtual network), so the LUM server is unable to reply messages (I checked this with wireshark). On host side it is a Mandriva 2009 32bit.

I went back again to 2.2.4 a few minutes ago, and now it is working fine again.

I have had this problem over a year and a half ago, by that time I compiled a SVN version that fixed that problem, and months later I started using 2.x versions that didn't had the problem, so it seems that is a regresion problem in the NAT engine.

[vasily Levchenko]

Replying to baturix:

I am having this issue with 3.0.6 and 3.0.4.

I run a LUM license server in a windows guest. It uses an UDP protocol and it is not working because the NAT engine seems to be changing the source IP with the IP of the hosts (in the virtual network), so the LUM server is unable to reply messages (I checked this with wireshark). On host side it is a Mandriva 2009 32bit.

I went back again to 2.2.4 a few minutes ago, and now it is working fine again.

I have had this problem over a year and a half ago, by that time I compiled a SVN version that fixed that problem, and months later I started using 2.x versions that didn't had the problem, so it seems that is a regresion problem in the NAT engine.

Does it repeat for you in 3.0.8? If yes please open other defect, because this ticket was around ICMP problem.

[rimvis]

i have same problem whit that one using 3.0.12

UBUNTU 9.10 PING TEST:
Bytes Source Seq Time Units
64 88.198.19.108 1 39.9 ms
64 88.198.19.108 2 38.6 ms
64 88.198.19.108 3 38.8 ms
64 88.198.19.108 4 38.5 ms
64 88.198.19.108 5 38.0 ms
Time minimum: 38.00 ms
Time average: 38.95 ms
Time maximum: 39.90 ms
Packets transmitted: 5
Packets received: 5
Successful packets: 100%

VIRTUALBOX whit firewall standard on WINXP
Reply from 88.198.19.108: bytes=32 time=39ms TTL=127
Reply from 88.198.19.108: bytes=32 time=297ms TTL=127
Reply from 88.198.19.108: bytes=32 time=44ms TTL=127
Reply from 88.198.19.108: bytes=32 time=2291ms TTL=127

Ping statistics for 88.198.19.108:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 2291ms, Average = 667ms

[vasily Levchenko]

Replying to ghostdog:

i have same problem whit that one using 3.0.12

Could you please attach ​pcap files for guest and host network activity and log file?

[vasily Levchenko]

No response closing. Please fill free to open if problem still persists for you?