the option --nataliasmode1 sameports is not honoured -> fixed in 5.2.18

[grocanar]

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.

[aleksk]

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)

# mount -t nfs -o v3,rw,relatime,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp nfsserver:/nfs1/home/username /mnt
[...]
15:08:52.953210 IP 10.0.2.15.923 > 10.x.xx.xxx.53163: Flags [S], seq 241298353, win 14600, options [mss 1460,sackOK,TS val 4294722997 ecr 0,nop,wscale 7], length 0
15:08:53.061436 IP 10.x.xx.xxx.53163 > 10.0.2.15.923: Flags [S.], seq 8640001, ack 241298354, win 65535, options [mss 1460], length 0
15:08:53.061466 IP 10.0.2.15.923 > 10.x.xx.xxx.53163: Flags [.], ack 1, win 14600, length 0
15:08:53.061753 IP 10.0.2.15.923 > 10.x.xx.xxx.53163: Flags [P.], seq 1:45, ack 1, win 14600, length 44
15:08:53.062033 IP 10.x.xx.xxx.53163 > 10.0.2.15.923: Flags [.], ack 45, win 65535, length 0
[...]
mount.nfs: access denied by server while mounting nfsserver:/nfs1/home/username
[...]
15:08:53.273355 IP 10.0.2.15.923 > 10.x.xx.xxx.53163: Flags [F.], seq 173, ack 61, win 14600, length 0
15:08:53.273636 IP 10.x.xx.xxx.53163 > 10.0.2.15.923: Flags [.], ack 174, win 65535, length 0
15:08:53.380984 IP 10.x.xx.xxx.53163 > 10.0.2.15.923: Flags [F.], seq 61, ack 174, win 65535, length 0

---

b.) (On the hypervisor (parent) system)

15:08:54.016438 IP 10.y.yy.yyy.33158 > 10.x.xx.xxx.53163: Flags [S], seq 3296137816, win 14600, options [mss 1460,sackOK,TS val 1211755402 ecr 0,nop,wscale 8], length 0
15:08:54.124129 IP 10.x.xx.xxx.53163 > 10.y.yy.yyy.33158: Flags [S.], seq 3240070866, ack 3296137817, win 14480, options [mss 1360,sackOK,TS val 900201039 ecr 1211755402,nop,wscale 8], length 0
15:08:54.124156 IP 10.y.yy.yyy.33158 > 10.x.xx.xxx.53163: Flags [.], ack 1, win 58, options [nop,nop,TS val 1211755510 ecr 900201039], length 0
15:08:54.124896 IP 10.y.yy.yyy.33158 > 10.x.xx.xxx.53163: Flags [P.], seq 1:45, ack 1, win 58, options [nop,nop,TS val 1211755511 ecr 900201039], length 44
15:08:54.229739 IP 10.x.xx.xxx.53163 > 10.y.yy.yyy.33158: Flags [.], ack 45, win 57, options [nop,nop,TS val 900201146 ecr 1211755511], length 0
15:08:54.229758 IP 10.x.xx.xxx.53163 > 10.y.yy.yyy.33158: Flags [P.], seq 1:29, ack 45, win 57, options [nop,nop,TS val 900201146 ecr 1211755511], length 28
15:08:54.229765 IP 10.y.yy.yyy.33158 > 10.x.xx.xxx.53163: Flags [.], ack 29, win 58, options [nop,nop,TS val 1211755615 ecr 900201146], length 0
15:08:54.230558 IP 10.y.yy.yyy.33158 > 10.x.xx.xxx.53163: Flags [P.], seq 45:173, ack 29, win 58, options [nop,nop,TS val 1211755616 ecr 900201146], length 128
15:08:54.335754 IP 10.x.xx.xxx.53163 > 10.y.yy.yyy.33158: Flags [P.], seq 29:61, ack 173, win 61, options [nop,nop,TS val 900201252 ecr 1211755616], length 32
15:08:54.336401 IP 10.y.yy.yyy.33158 > 10.x.xx.xxx.53163: Flags [F.], seq 173, ack 61, win 58, options [nop,nop,TS val 1211755722 ecr 900201252], length 0
15:08:54.443523 IP 10.x.xx.xxx.53163 > 10.y.yy.yyy.33158: Flags [F.], seq 61, ack 174, win 61, options [nop,nop,TS val 900201359 ecr 1211755722], length 0

---

c.) On the NFS server itself:

Nov 26 10:08:54 nfsserver rpc.mountd[1112]: refused mount request from 10.y.yy.yyy for /nfs1/home/username (/nfs1): illegal port 33158

---

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!

[aleksk]

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

[Frank Mehnert]

It is true that ports below 1024 are reserved for system users. VirtualBox runs as normal user process, therefore these ports are not available.

[chrijm]

Same here, but for ports > 1024 (so not restricted).

[chrijm]

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.

[Valery Ushakov]

Unfortunately, sameport has always been broken and is unlikely to get fixed soon.

[Socratis]

Fixed is part of 5.2.18, according to the Changelog.