Opened 10 years ago
Closed 6 years ago
#13000 closed defect (fixed)
the option --nataliasmode1 sameports is not honoured -> fixed in 5.2.18
Reported by: | grocanar | Owned by: | |
---|---|---|---|
Component: | network/NAT | Version: | VirtualBox 4.3.10 |
Keywords: | Cc: | ||
Guest type: | Linux | Host type: | other |
Description
Hi
We have created a Centos 6.4 guests in virtualbox windows hosts. We lack ip adress in our network then we use nat to access to the network. this guest should mount NFS exports in a secure manner ( aka use port udner 1024) Therefore we use the following commands as state in the manual VBoxManage modifyvm "Linux Guest" --nataliasmode1 sameports
bt when we launch the nfs client on the guest the nat doesn't use the same ports and it uses port over 1024.
Change History (8)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
One thing i thought of since writing the above that may be related (and possibly a cause):
I am running virtualbox as a non-privileged user, so perhaps what's happening is that since root is typically required to bind on ports less than 1024. As a result, perhaps NAT just isn't able to create outbound connections. I can't (won't) run virtualbox as root due to security considerations, however since there are virtualbox services that ARE running as root, i would imagine this shouldn't be the cause. I'll investigate to see if i can get setcap to allow this for processes under my username (but not sure how much success i'll have as I'm not sure which process actually is responsible for the NATing).
Just mentioning this in case it is related (though i hope it's not the culprit).
comment:3 by , 9 years ago
It is true that ports below 1024 are reserved for system users. VirtualBox runs as normal user process, therefore these ports are not available.
comment:5 by , 8 years ago
I tried this on both an OSX host and a Windows host. With both hosts I tested it with a Windows guest and a Linux guest. In all cases, the sameports options had no effect. My tests attempted to open TCP and UDP ports in the 65000-65254 range. Both TCP and UDP traffic were assigned random ports (always in the 40000-59999 range). I confirmed ip and ports using network captures on both the host and the guest.
I verified in all cases that the machine was set to use NAT and the machine's XML file indeed had the Alias setting:
<NAT> <Alias use-same-ports="true"/> </NAT>
I tried this on v4.3.29 and versions 5.0.24 through 5.1.2 with the same results every time. I did not try a Linux Host nor an OSX guest.
comment:6 by , 8 years ago
Unfortunately, sameport
has always been broken and is unlikely to get fixed soon.
comment:8 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Summary: | the option --nataliasmode1 sameports is not honoured → the option --nataliasmode1 sameports is not honoured -> fixed in 5.2.18 |
Could someone please look into/fix this? I am using VirtualBox 5.0.8 (nothing related to NAT aliasing in latest 5.0.10 changelog about this so i'm still on 5.0.8 as i have standardized on that version until there's a fix). My Guest and Hypervisor are CentOS 6.6 (NFS server is CentOS 6.4).
Will there there ever be any updates to this? This is seriously causing issues for us as we are unable to mount home directories and will be a block before we can consider this technology/product usable in our environment:
Below is some tcpdump output during an NFS mount attempt on
a.) 10.0.0.2 the guest host's (NATd) IP also showing the nfs mount command used
b.) 10.x.xx.xxx - hypervisor host (where i've tried specifying nataliasmode1 with 'sameports' setting, 'proxyonly' setting, as well as both), and
c.) 10.y.yy.yyy - showing the rpc.mountd failure entry on the nfs server itself
a.) On the guest (which has eth0 NAT'd)
b.) (On the hypervisor (parent) system)
c.) On the NFS server itself:
As you can see, the server ends up seeing 33158 as the source port whereas on the machine it's clearly trying to properly use a privileged port 923.
For that matter, changing this doesn't give any confirmation, the output of showvminfo doesn't change at all either so I'm starting to suspect making a change to this setting results in a NOOP.
Please advise!