VirtualBox

Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

#4540 closed defect (fixed)

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

Reported by: Jason Desai Owned by:
Component: network/NAT Version: VirtualBox 3.0.4
Keywords: Cc:
Guest type: other Host type: other

Description

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.

Attachments (6)

ping.pcap (2.5 KB ) - added by Jason Desai 15 years ago.
Wireshark capture of a ping of www.virtualbox.org, showing wrong source address on replies.
VBox.log (46.4 KB ) - added by Jason Desai 15 years ago.
Log File
VBox.2.log (56.2 KB ) - added by Georg Glaser 15 years ago.
ping.2.pcap (40 bytes ) - added by Georg Glaser 15 years ago.
ping.3.pcap (26.9 KB ) - added by Georg Glaser 15 years ago.
screenshot.png (295.0 KB ) - added by Georg Glaser 15 years ago.

Download all attachments as: .zip

Change History (28)

by Jason Desai, 15 years ago

Attachment: ping.pcap added

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

comment:1 by Jason Desai, 15 years ago

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

comment:2 by vasily Levchenko, 15 years ago

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

by Jason Desai, 15 years ago

Attachment: VBox.log added

Log File

comment:3 by Jason Desai, 15 years ago

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

in reply to:  3 comment:4 by vasily Levchenko, 15 years ago

Replying to jasetheace:

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

thank you.

comment:5 by vasily Levchenko, 15 years ago

Summary: NAT does not seem to properly set the source ip of some incoming packetsNAT does not seem to properly set the source ip of some incoming packets -> fixed in SVN

comment:6 by Frank Mehnert, 15 years ago

Component: othernetwork/NAT

comment:7 by Sander van Leeuwen, 15 years ago

Resolution: fixed
Status: newclosed

comment:8 by Georg Glaser, 15 years ago

Resolution: fixed
Status: closedreopened

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

in reply to:  8 comment:9 by vasily Levchenko, 15 years ago

Replying to fuzzie: Could you please attach the log?

comment:10 by vasily Levchenko, 15 years ago

Summary: NAT does not seem to properly set the source ip of some incoming packets -> fixed in SVNNAT does not seem to properly set the source ip of some incoming packets
Version: VirtualBox 3.0.2VirtualBox 3.0.4

by Georg Glaser, 15 years ago

Attachment: VBox.2.log added

comment:11 by vasily Levchenko, 15 years ago

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).

in reply to:  8 ; comment:12 by Jason Desai, 15 years ago

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.

by Georg Glaser, 15 years ago

Attachment: ping.2.pcap added

in reply to:  12 comment:13 by vasily Levchenko, 15 years ago

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

by Georg Glaser, 15 years ago

Attachment: ping.3.pcap added

by Georg Glaser, 15 years ago

Attachment: screenshot.png added

comment:14 by Georg Glaser, 15 years ago

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?

in reply to:  14 comment:15 by vasily Levchenko, 15 years ago

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.

comment:16 by Georg Glaser, 15 years ago

ok, so please close this ticket again :)

comment:17 by vasily Levchenko, 15 years ago

Resolution: fixed
Status: reopenedclosed

comment:18 by baturix, 14 years ago

Resolution: fixed
Status: closedreopened

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.

in reply to:  18 comment:19 by vasily Levchenko, 14 years ago

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.

comment:20 by rimvis, 14 years ago

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

in reply to:  20 comment:21 by vasily Levchenko, 14 years ago

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?

comment:22 by vasily Levchenko, 14 years ago

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use