Re: ms-nfs41-client mount to FreeBSD 16.0 nfsd fails in VM with NAT

On Thu, Jun 4, 2026 at 4:39 AM Lionel Cons <[email protected]> wrote:
>
> On Wed, 3 Jun 2026 at 08:07, Rick Macklem <[email protected]> wrote:
> >
> > On Tue, Jun 2, 2026 at 9:52 AM Lionel Cons <[email protected]> wrote:
> > >
> > > We've hit a problem with ms-nfs41-client release 2026-06-01 with FreeBSD 16.0:
> > >
> > > If Windows runs in a VM with NAT an attempt to mount fails with Error
> > > Code 59 (Unexpected network error), but if the VM has an IPv4 or IPv6
> > > address the mount succeeds.
> > >
> > > Lab technician says that it might be a problem that FreeBSD nfsd
> > > rejects TCP connections from ports < 1024, "... because NAT cannot do
> > > that automatically... " (yay, cryptic, and then he went home...).
> > >
> > > Can anyone please elaborate this in more detail?
> > He might have meant the reverse. By default, the FreeBSD nfsd requires
> > that a client use a reserved port# (which is < 1024).
> >
> > If that is the problem, you can do the following:
> > - edit /etc/rc.conf and put a line in it like
> > nfs_reserved_port_only="NO"
> > and then
> > # sysctl vfs.nfsd.nfs_privport=0
> > - to change it immediately, without rebooting the server#
>
> That fixed the problem.
>
> Is there a setting which allows this per-export?
No.

>
> > There are a few situations where requiring a reserved port#
> > improves security, but it is mostly bunk. However, FreeBSD
> > doesn't like defaults to change (it's referred to as a POLA
> > violation), so the default remains "require it".
>
> Depends on the site. If this is a documented restriction, and you
> violate that in the production server farms, then I will pay a
> personal visit to the offending person. Outside the production farm I
> will not care much.
Well, in FreeBSD it is in "man mount_nfs". In general, the "only allow
clients to use reserved port#s" has existed for NFS as long as I can
recall (decades). I think Sun called it "secure NFS" long ago, although
that was pushing it.

It does improve security for some specific cases.
Basically, if "su/root" on the client machine is trusted, but other
processes/threads (user logins in the old days) are not, this
protects against a malicious NFS client run by a "user".
Anyone can easily write their own NFS client. rpcgen does
a lot of the work and there are also libraries and lots of
sample code. Without the reserved port# restriction, any
user can construct one and do mounts from any machines
exports (or firewalls) give access to, if they can get it to
run on the systems.
--> This might be discussed in the NFSv4 Security draft
     authored by David Noveck?

At one time, I had FreeBSD configured to allow NFSv4
mounts without the restriction, which is consistent with
what the original RFC3530 specified. (RFC3530 also
assumed AUTH_SYS was going away in favour of
RPCSEC_GSS.)
--> Others complained this introduced a security
     vulnerability.
--> It was also flagged as a security vulnerability
     be some widely used security checking software.

If this doesn't provide enhanced security for your
setup, you just disable it.

rick

>
> Lionel
>