NFS export locked to a VPN address: what it does not prove
An export rule checks where a packet came from; AUTH_SYS asserts a local UID and Kerberos authenticates a user. Decide which one your file service needs.
A host exports a directory to a VPN address, the mount succeeds, and the design gets written down as authenticated. What that rule actually constrains is where the packets appear to come from. Whether the person driving the file operation is who they claim to be depends on the NFS security flavour, and on most exports of this kind nobody changed it from the default.
Three identities can show up in one request
The VPN peer carries an enrolled identity such as a client certificate or a peer key. The inner IP packet carries a source address. The file operation carries whatever user credential its NFS mechanism supplies. A design that treats the address as standing in for all three has quietly assumed the part it needed to verify.
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
Writing those three rows down is the whole exercise. Most of the argument about whether an export is safe collapses once it is clear which row each control lives in.
Address ownership is an implementation detail
A gateway can assign a tunnel address to an accepted peer, or authorize a routed subnet for it. Whether the implementation then refuses a packet whose inner source belongs to a different client is a property of that implementation, and it is worth checking rather than assuming.
Traditional Community OpenVPN user-space server code, for instance, can reject a source associated with another client before the packet is delivered through the TUN device. That is an address-ownership check with real value, and it is still not NFS user authentication, because it says nothing about which account performs the operation.
Source translation erodes even that. A NAT gateway can present every client as one address, at which point an export rule cannot distinguish between the people behind it. The rule's apparent precision then becomes a fiction maintained by the diagram. If the export matters, keep the addressing explicit rather than letting a translator decide who counts as whom.
Read the security flavour before trusting the export
Red Hat's NFS guidance separates sec=sys, which uses local UNIX UIDs and GIDs through AUTH_SYS, from the Kerberos modes. krb5 adds user authentication, krb5i adds integrity protection, and krb5p adds privacy protection for the traffic.
The AUTH_SYS credential contains fields such as the caller UID and group IDs, and RFC 5531 warns plainly that this flavour provides no security by itself and depends on external protection. Running it inside a VPN supplies protection for the transport and changes nothing about the assertion inside the packet.
exportfs -v
showmount -e nfs.example.internalRead the flavour in that output before you read the client list. An export that appears restricted may be restricted only by address while every caller still asserts whatever UID it likes.
Choose the model, then keep the permissions
Pick the file-service authentication model appropriate to clients you actually administer. Kerberos requires an identity and service deployment behind it, so changing one mount option is not a migration and will simply fail until the Kerberos domain, principals and keytabs exist.
Under either model, keep the export permissions and the filesystem authorization that constrain what the authenticated principal may do. Authentication tells you who is asking; authorization decides whether the answer should be yes. Collapsing those two into one setting is how a migration ends up granting more than the old configuration did.
Use the address rule for its real purpose
Restricting the service to the approved path and sources remains worthwhile, including the host input policy when the VPN endpoint and the NFS server share a machine. Rules that forward traffic do not govern requests aimed at a service running locally on the same host. That gap explains a surprising number of exports that were meant to be private. Check the local input policy explicitly rather than assuming the tunnel rules cover it.
Check that another interface or a source-translated gateway cannot satisfy the rule unexpectedly, and treat that as a reason to establish provenance rather than a claim that forging an address guarantees a working mount.
Run three acceptance cases rather than one. Start with an approved client acting as an approved user, then repeat from a peer that was never approved, then attempt something the approved user is still not allowed to do. Ask afterwards what changes if an authorized client is compromised, because transport authentication does not make every process on that machine trustworthy. A stolen certificate and a curious local account are different problems with different controls.