NFS Re-export Across a VPN Is Not Packet Forwarding

A Linux box joins a VPN, mounts a remote NFS export, and then serves that mount to another set of clients. The arrangement looks like routing with extra steps, and that is the first wrong assumption. The middle machine is a client of the upstream server and a server to the downstream clients, and it takes part in both file-service relationships. Packet forwarding has no opinion about filehandles, locking, or filesystem identity; a re-export does.

Start by asking whether the downstream clients could reach the original server directly. If they can, the middle machine is optional.

Three models, three consistency stories

Direct mount is the simplest: each client mounts the original server through the tunnel, and that server's export policy governs access. Re-export is the middle machine presenting a different service boundary, which is useful when the client-facing network must not reach the server directly. Replication is a third model, and it changes the question from consistency to synchronisation and conflict resolution.

Do not describe a replicated copy as if it were a live re-export. The failure modes differ, and a user who expects every operation to reach the original filesystem will be surprised during a link outage.

Identity outlives the mount command

Re-exports need an explicit filesystem ID, and that identity has to survive restarts and configuration rebuilds. The kernel documentation is clear on the requirement, and it also warns that crossmnt does not remove the need to export child filesystems with their own IDs. A directory tree that looks continuous to a user can cross several filesystem boundaries. Current nfs-utils can allocate IDs automatically for supported configurations, and when it does, its database becomes part of the gateway's state. Treat those IDs as service identity rather than disposable files.

Filehandles are the other identity boundary: a re-export wraps the original handle, which makes it larger and can exceed a client's limit. A successful mount does not prove that every export layout is compatible.

Not every NFS feature survives the middle machine

The kernel's re-export guide states that the re-exporting server does not support locking or delegation requests. Applications that depend on those operations need a different path or a design that was verified against them. A successful mount and a working directory listing do not show that the application's real operations work.

User identity and export policy also matter at each hop. A VPN login proves that a network participant authenticated; it does not authorize an NFS user, and it does not forward a client's credentials across the gateway.

The gateway has two upstream dependencies

The gateway depends on the VPN for the upstream mount and on the upstream server for the filesystem itself. A local export process that is still running cannot make unavailable storage healthy. Plan start order, reconnect behaviour, and server restarts, including what happens to filehandles clients already hold. A client that mounted through the gateway and lost its handle needs a remount, and that is an operational event rather than a transparent recovery.

If all the requirement ever needed was private IP reachability, routing directly to the original server is the simpler architecture. The re-export should exist for a reason that survives being written down.

Test the workload, not the mount

Exercise the real file workload in a controlled environment: the operations the application performs, the file sizes it uses, and the concurrency it expects. Watch for the feature gaps rather than only for transport errors. Then record which model you chose and why, because the next person will otherwise assume the gateway is a router.

A re-export is legitimate when it exists for a deliberate reason, such as an isolated client network or a controlled version boundary. It is a poor accident, and the difference is whether someone decided it.