The NFS client implementation on NetBSD is very picky about the source
address of received NFS packets - unlike SunOS et al, it discards (or
otherwise doesn't use) packets with source addresses other than the
place it thinks it is connecting to. For example, let's say I have the
following network (mine is actually more complicated, but you get the
idea):

	--------------------------------------------------------
	    | (192.0.2.20)	192.0.2.0/24	    | (192.0.2.1)
        +--------+				+--------+
	| server |				| router |
	+--------+				+--------+
	    | (192.0.3.20)	192.0.3.0/24	    | (192.0.3.1)
	  ---------------------------------------------------------
			     | (192.0.3.21)
			+---------+
			| client  |
			+---------+

(server has IPFORWARDING turned off, as it is dual homed only for the
purpose of making access faster to clients on both nets, but shouldn't
be bogged down routing packets)

If client is NetBSD and I put something like:

	192.0.3.20:/exported	/imported nfs rw 0 0

in /etc/fstab, it will mount just fine, but if I put:


	192.0.2.20:/exported	/imported nfs rw 0 0

it will fail, since the return packet from 192.0.2.20 will go out the
192.0.3.20 interface, getting that address as its source.

If client is SunOS or some other low life system, it will happily mount
the share and get on with life, ignoring the fact that the packets coming
back from the server are from a different IP address than that specified
in fstab (and in the outgoing packets); even if the source address
*changes* during the life of the mount, SunOS doesn't complain (while
NetBSD gets constipated). I would like to have the ability to change
NetBSD's behavior in this case to be like SunOS.

Now, before anyone flies off the handle, I realize that discarding
packets from a different source address is (on the surface) nice from a
security point of view (although it doesn't mean much if someone else on
the same subnet spoofs the servers address). My problem is that I'm in a
reasonably secure environment, and I have a true need for this to
work.

Normally, all this can be compensated for by simply determining which
interface on the server is "closest" to the client, and specifying that
address in fstab. That doesn't work, however, when a machine on the net
that is acting as a router goes down, creating a different path between
the client and server - since this happens in real time, it can't be
compensated for in a configuration file.

Such a thing happened tonight when I trashed a NetBSD machine that was
acting as a router between our 100 Mbit net and our 10Mbit engineering
net, leaving two P6-200 NetBSD machines accessible only indirectly via a
10Mbit card on one of the servers that was connected to yet a third net
(don't even ask why it's there - all very ugly :-)). So I reconfigured
gated on that machine to propogate routes through this interface (I had
been keeping it private before) and most things started working, but the
2nd (non dual-homed) P6 was in a semi-hung state because it had mounted
a share from a HP-UX server that was dual-homed on the engineering
10Mbit as well as the "3rd" 10Mbit net; this machine suddenly started
talking to the P6 via the "third net" interface, and NFS stopped
working. (In the meantime, a SunOS machine on the engineering net that
had mounted a file from the P6 NetBSD continued to work properly, even
though the source address of packets coming from the P6 had changed). I
would really much prefer it if all my redundant connections between nets
actually came to some good when one machine or another went down.

So: 1) Is there a simple way for me to change this behavior? 2) Would
core consider making such a change that was configurable with sysctl
(but defaulted to the more secure, ie current, case)?