Opened 12 years ago
Closed 10 years ago
#11871 closed defect (fixed)
NAT drops packets bigger than 388 byte towards guest
Reported by: | Lukas Tribus | Owned by: | |
---|---|---|---|
Component: | network/NAT | Version: | VirtualBox 4.2.12 |
Keywords: | mtu | Cc: | |
Guest type: | all | Host type: | all |
Description
NAT mode does not work for me, because all packets bigger than 388 byte (IP packet length; 368 byte IP payload or 360 byte ICMP payload) are dropped.
The test is as simple as:
ping google.com -s 360 ping google.com -s 361
or on Windows guests:
ping google.com -l 360 ping google.com -l 361
The former (360 byte ICMP payload) works, while the latter (361 byte ICMP payload) doesn't.
I can reliably reproduce this with both Linux and Windows guests (32 and 64bit), on different hardware. The host always runs Windows Vista or Windows 7, both 64 bit. I did not test different host OS'.
This is with VirtualBox-4.2.12, but I can also reproduce this with the old VirtualBox-3.2.16.
The traffic of the testcase has been captured:
- nictrace.cap
- via the nictrace feature; it is clear that the answer packets do not reach the guests
- host-dump.cap
- via Wireshark on the host; all answer packets are seen (frame >= 25)
I have no clue why others don't see this behavior; on all my VirtualBox installations I see exactly this issue, and they are different installations on different hardware with different software.
Bridging mode works perfectly fine on those installations.
Attachments (4)
Change History (12)
by , 12 years ago
by , 12 years ago
Attachment: | nictrace.cap added |
---|
by , 12 years ago
Attachment: | host-dump.cap added |
---|
comment:1 by , 12 years ago
comment:2 by , 12 years ago
The initial problem was that my DNS servers are within the default NAT range 10.0.2.0/24, so the guest could never contact them. I erroneously concluded that DNS wasn't working because of MTU problems and I fixed it only now, by changing the NAT range in VirtualBox to something which doesn't conflict with my upstream DNS servers.
So if I understand this correctly, this is a known limitation impacting ICMP traffic only; when the host is Windows and NAT is used? Perhaps this should be made more clear in the manual?
Chapter 6, NAT limitations:
While ICMP support has been improved with VirtualBox 2.1 (ping should now work), some other tools may not work reliably.
I suppose we should add your statement from above:
Please note: for Windows hosts ICMP isn't implemented in socket API, instead ICMP API used, which has own bottlenecks and couldn't be used as diagnostic tool. This affects all guests.
by , 12 years ago
Attachment: | vbox-doc-win-nat-icmp-clarification.diff added |
---|
doc clarification patch
follow-up: 5 comment:4 by , 10 years ago
Actually we changed the implementation. Could you check if this build fixes the problem for you?
comment:5 by , 10 years ago
I only checked it now (no notifications possible here?) and the link doesn't work.
Should I wait for the next Virtualbox 4.3 release?
comment:6 by , 10 years ago
Re notifications: Check your email address in the preferences. Here is a new build.
comment:7 by , 10 years ago
I can confirm that this issue is no longer occurring in the newer testbuilds, Thank you!
What was initial problem (before you had gone down to ping diagnostic)? (please note: for Windows host ICMP isn't implemented in socket API, instead ICMP API used, which has own bottlenecks and couldn't be used as diagnostic tool).