Opened 8 years ago
Last modified 7 years ago
#15303 reopened defect
NAT host adapter responds to traffic when it shouldn't
| Reported by: | Mike446 | Owned by: | |
|---|---|---|---|
| Component: | network/NAT | Version: | |
| Keywords: | Cc: | virtualbox@… | |
| Guest type: | all | Host type: | other |
Description (last modified by )
When using a NAT network, the host adapter will generate TCP RST packets in response to packets that are not destined for that interface. For example, here we have the following network setup:
52:54:00:12:35:02 10.0.2.2 VirtualBox router 08:00:27:7c:00:6c 10.0.2.15 VM
And the VM sends this packet:
TCP SYN Src: Eth 08:00:27:7c:00:6c / IP 10.0.2.15 / TCP 15717 Dst: Eth 08:00:27:7c:00:6d / IP 10.0.2.100 / TCP 80
Then, the VM will receive this spurious packet:
TCP RST,ACK Src: Eth 52:54:00:12:35:02 / IP 10.0.2.100 / TCP 80 Dst: Eth 08:00:27:7c:00:6c / IP 10.0.2.15 / TCP 15717
Note the source MAC. This is the host adapter's MAC. The expected result is that no packet will be sent in response to the original packet above, since the target host does not exist on the network and any other host receiving the packet should disregard it since the destination MAC does not match their MAC.
I have attached a pcap of the problem that was generated like this (nping is part of nmap):
arping -I enp0s3 -c 1 10.0.2.2 nping --tcp --dest-mac 08:00:27:7c:00:6d 10.0.2.100
Tested with VirtualBox 4.3.36, 5.0.12 and 5.0.16 using Debian, Ubuntu and FreeBSD.
Attachments (1)
Change History (6)
by , 8 years ago
| Attachment: | vbox-tcp-rst.pcap added |
|---|
comment:1 by , 8 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 8 years ago
| Description: | modified (diff) |
|---|---|
| priority: | major → minor |
comment:3 by , 8 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:4 by , 7 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Reopening the bug as this problem still exists in "VirtualBox Graphical User Interface Version 5.0.40_Ubuntu r115130" version.


This should have been fixed in 5.0.24