VirtualBox

Ticket #4540 (closed defect: fixed)

Opened 5 years ago

Last modified 4 years ago

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

Reported by: jasetheace Owned by:
Priority: major 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

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

Change History

Changed 5 years ago by jasetheace

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

comment:1 Changed 5 years ago by jasetheace

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

comment:2 Changed 5 years ago by Hachiman

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

Changed 5 years ago by jasetheace

Log File

comment:3 follow-up: ↓ 4 Changed 5 years ago by jasetheace

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

comment:4 in reply to: ↑ 3 Changed 5 years ago by Hachiman

Replying to jasetheace:

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

thank you.

comment:5 Changed 5 years ago by Hachiman

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

comment:6 Changed 5 years ago by frank

  • Component changed from other to network/NAT

comment:7 Changed 5 years ago by sandervl73

  • Status changed from new to closed
  • Resolution set to fixed

comment:8 follow-ups: ↓ 9 ↓ 12 Changed 5 years ago by fuzzie

  • Status changed from closed to reopened
  • Resolution fixed deleted

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

comment:9 in reply to: ↑ 8 Changed 5 years ago by Hachiman

Replying to fuzzie: Could you please attach the log?

comment:10 Changed 5 years ago by Hachiman

  • Version changed from VirtualBox 3.0.2 to VirtualBox 3.0.4
  • Summary changed from NAT does not seem to properly set the source ip of some incoming packets -> fixed in SVN to NAT does not seem to properly set the source ip of some incoming packets

Changed 5 years ago by fuzzie

comment:11 Changed 5 years ago by Hachiman

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

comment:12 in reply to: ↑ 8 ; follow-up: ↓ 13 Changed 5 years ago by jasetheace

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.

Changed 5 years ago by fuzzie

comment:13 in reply to: ↑ 12 Changed 5 years ago by Hachiman

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

Changed 5 years ago by fuzzie

Changed 5 years ago by fuzzie

comment:14 follow-up: ↓ 15 Changed 5 years ago by fuzzie

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?

comment:15 in reply to: ↑ 14 Changed 5 years ago by Hachiman

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 Changed 5 years ago by fuzzie

ok, so please close this ticket again :)

comment:17 Changed 5 years ago by Hachiman

  • Status changed from reopened to closed
  • Resolution set to fixed

comment:18 follow-up: ↓ 19 Changed 5 years ago by baturix

  • Status changed from closed to reopened
  • Resolution fixed deleted

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.

comment:19 in reply to: ↑ 18 Changed 5 years ago by Hachiman

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 follow-up: ↓ 21 Changed 4 years ago by ghostdog

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

comment:21 in reply to: ↑ 20 Changed 4 years ago by Hachiman

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 Changed 4 years ago by Hachiman

  • Status changed from reopened to closed
  • Resolution set to fixed

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

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use