NFS mount over VPN, through NAT/firewall

Hello!

Despite multiple google searches, I have yet to find a clear
description of how to setup an NFS mount over a VPN (with a
NAT box sitting in the middle). Specifically, I have:

Home:
- Redhat Linux 9.0
- Linksys router acting as a NAT box to my PPPOE DSL connection
- IPtables set up (via firestarter) with the VPN servers and
select work machines listed as trusted hosts
- working VPN client for Linux (I already ssh into the work
machines regularly without difficulty)
- the VPN is enabled only when needed

Work:
- Multiple machines (Linux 7.3, Linux 8.0, SGI IRIX) that I
would like to NFS export my home directory from, to be mounted
by my home machine when I activate the VPN.
- I don't have root access, so I'll be asking sys-admins to
handle any root authorized tasks

Can anyone point me to a good resource that describes what I need
to do on both ends of the VPN (work and home machines) to enable
this setup? If you're up to it, an explanatory post would be even
better!

I'm quite comfortable with UNIX/Linux, but have little background
in setting up networks. (I need a second machine at home so I can
experiment...)

Many thanks for any help!

-Brian

(E-Mail Removed) writes:
>
> Can anyone point me to a good resource that describes what I need
> to do on both ends of the VPN (work and home machines) to enable
> this setup? If you're up to it, an explanatory post would be even
> better!

Actually, it should "just work". Presumably, the VPN server is
assigning you a "trusted" IP address on the workplace LAN. If the NFS
machines exporting the directories are set up to permit access to this
trusted IP address, you just need to mount the filesystems normally.

(Note that, as with any NFS mount, you need to either make sure your
home computer uses the same uids and gids as the servers, especially
for your username and group, or else set up some other mechanism to do
the mapping. See the "exports(5)" manpage under "User ID Mapping".)

The NATting isn't an issue. The VPN connection itself is being
NATted, but the NFS traffic is flowing over the tunnel without address
translation.

The iptables configuration might be an issue. You need to make sure
that the NFS traffic arriving from the various work servers won't be
refused. I haven't used Firestarter, so I can't give you very
concrete advice. You may need to list all the machines serving you
NFS directories as trusted hosts (or it may just work).

Once you've verified that you can manually mount and access NFS
directories when the VPN is up, you can automate the process by
sticking appropriate entries in "/etc/fstab":

workhost1:/home/jonesbr /the/local/mountpoint/one nfs noauto,intr 0 0
workhost2:/home/jonesbr /the/local/mountpoint/two nfs noauto,intr 0 0

The "noauto" option ensures they won't be automatically mounted on
bootup. The "intr" option ensures you can Ctrl-C out of a stuck file
operation if your VPN goes down unexpectedly.

Assuming your VPN is set up with a PPTP client that uses "pppd", the
scripts in "/etc/ppp/ip-up.d" and "/etc/ppp/ip-down.d" will be called
when the connection goes up or down, and you can stick files in there
to mount and unmount the directories. Since you only want these run
when the VPN goes up or down (and not when your PPPOE---which also
uses "pppd" and runs these scripts---goes up or down), you want to add
an identifying line to the "/etc/ppp/peers/xxx" file for your VPN:

ipparam workvpn

and then check for this value in your scripts:

/etc/ppp/ip-up.d/mounthome:
#!/bin/sh
if [ "$PPP_IPPARAM" = workvpn ]
then
mount /the/local/mountpoint/one
mount /the/local/mountpoint/two
fi

/etc/ppp/ip-down.d/mounthome:
#!/bin/sh
if [ "$PPP_IPPARAM" = workvpn ]
then
umount /the/local/mountpoint/one
umount /the/local/mountpoint/two
fi

Make sure to "chmod 755" these scripts.

--
Kevin <(E-Mail Removed)>

I have set up a CIPE VPN, which works well with everything except NFS. If I
connect with a fast connection, such as wireless, NFS works fine. However,
if I connect via dialup, the performance is so bad, as to be useless. This
leads me to believe there's a problem with the speed difference between
dialup and my local lan (100 Mb), but I haven't a clue as to how to resolve
it.



(E-Mail Removed) wrote:

> Hello!
>
> Despite multiple google searches, I have yet to find a clear
> description of how to setup an NFS mount over a VPN (with a
> NAT box sitting in the middle). Specifically, I have:
>
> Home:
> - Redhat Linux 9.0
> - Linksys router acting as a NAT box to my PPPOE DSL connection
> - IPtables set up (via firestarter) with the VPN servers and
> select work machines listed as trusted hosts
> - working VPN client for Linux (I already ssh into the work
> machines regularly without difficulty)
> - the VPN is enabled only when needed
>
> Work:
> - Multiple machines (Linux 7.3, Linux 8.0, SGI IRIX) that I
> would like to NFS export my home directory from, to be mounted
> by my home machine when I activate the VPN.
> - I don't have root access, so I'll be asking sys-admins to
> handle any root authorized tasks
>
> Can anyone point me to a good resource that describes what I need
> to do on both ends of the VPN (work and home machines) to enable
> this setup? If you're up to it, an explanatory post would be even
> better!
>
> I'm quite comfortable with UNIX/Linux, but have little background
> in setting up networks. (I need a second machine at home so I can
> experiment...)
>
> Many thanks for any help!
>
> -Brian

--

Fundamentalism is fundamentally wrong.

To reply to this message, replace everything to the left of "@" with
james.knott.

Hi Kevin.

Thanks for the response - I appreciate the detail of your reply!

I think my primary difficulty involves how to map the UID/GID's
from the work machine to my home machine. I have one login
ID/UID/GID at work (which I can't control) and a separate login
ID/UID/GID at home (which I would obviously prefer not to
change).

The impression that I get from various searches is that the older
user-mode Linux NFS could map one UID or GID to another, but
that the newer kernel-mode Linux NFS can not (root squashing
and anonymous ID's aside). Any hints as to what I should be
looking for?

Thanks!

-Brian


Kevin Buhr <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> (E-Mail Removed) writes:
> >
> > Can anyone point me to a good resource that describes what I need
> > to do on both ends of the VPN (work and home machines) to enable
> > this setup? If you're up to it, an explanatory post would be even
> > better!
>
> Actually, it should "just work". Presumably, the VPN server is
> assigning you a "trusted" IP address on the workplace LAN. If the NFS
> machines exporting the directories are set up to permit access to this
> trusted IP address, you just need to mount the filesystems normally.
>
> (Note that, as with any NFS mount, you need to either make sure your
> home computer uses the same uids and gids as the servers, especially
> for your username and group, or else set up some other mechanism to do
> the mapping. See the "exports(5)" manpage under "User ID Mapping".)
>
> The NATting isn't an issue. The VPN connection itself is being
> NATted, but the NFS traffic is flowing over the tunnel without address
> translation.
>
> The iptables configuration might be an issue. You need to make sure
> that the NFS traffic arriving from the various work servers won't be
> refused. I haven't used Firestarter, so I can't give you very
> concrete advice. You may need to list all the machines serving you
> NFS directories as trusted hosts (or it may just work).
>
> Once you've verified that you can manually mount and access NFS
> directories when the VPN is up, you can automate the process by
> sticking appropriate entries in "/etc/fstab":
>
> workhost1:/home/jonesbr /the/local/mountpoint/one nfs noauto,intr 0 0
> workhost2:/home/jonesbr /the/local/mountpoint/two nfs noauto,intr 0 0
>
> The "noauto" option ensures they won't be automatically mounted on
> bootup. The "intr" option ensures you can Ctrl-C out of a stuck file
> operation if your VPN goes down unexpectedly.
>
> Assuming your VPN is set up with a PPTP client that uses "pppd", the
> scripts in "/etc/ppp/ip-up.d" and "/etc/ppp/ip-down.d" will be called
> when the connection goes up or down, and you can stick files in there
> to mount and unmount the directories. Since you only want these run
> when the VPN goes up or down (and not when your PPPOE---which also
> uses "pppd" and runs these scripts---goes up or down), you want to add
> an identifying line to the "/etc/ppp/peers/xxx" file for your VPN:
>
> ipparam workvpn
>
> and then check for this value in your scripts:
>
> /etc/ppp/ip-up.d/mounthome:
> #!/bin/sh
> if [ "$PPP_IPPARAM" = workvpn ]
> then
> mount /the/local/mountpoint/one
> mount /the/local/mountpoint/two
> fi
>
> /etc/ppp/ip-down.d/mounthome:
> #!/bin/sh
> if [ "$PPP_IPPARAM" = workvpn ]
> then
> umount /the/local/mountpoint/one
> umount /the/local/mountpoint/two
> fi
>
> Make sure to "chmod 755" these scripts.

(E-Mail Removed) writes:
>
> The impression that I get from various searches is that the older
> user-mode Linux NFS could map one UID or GID to another, but
> that the newer kernel-mode Linux NFS can not (root squashing
> and anonymous ID's aside).

Yes, I believe you're correct.

Probably the easiest thing to do is to change your home uid/gid, even
if that's a bit of a hassle.

However, an alternative you could try is to mount the external
directories in some convenient spot, say under "/external", without
any uid/gid mapping and then run a user-mode NFS server on your
*local* machine to re-export "/external" using one of the uid/gid
mapping schemes that the user-mode server supports (for example,
"map_static"). Then, mount "localhost:/external" to its final resting
place "/workfiles" and access your work files from there, letting the
local server perform the mapping.

Note that you must run the local user-mode NFS server "rpc.nfsd" and
the local mount daemon "rpc.mountd" with the "--re-export" option (see
rpc.nfsd(8) and rpc.mountd(8)) for this to have a chance of working.

Also, I've never tested it myself, so I have no idea if it'll really
work in the end.

--
Kevin <(E-Mail Removed)>