NFS on TCP Inside an OpenVPN UDP Tunnel: Two Transports

Carrying an NFS conversation that uses TCP inside a tunnel that carries UDP is entirely consistent, and it confuses people because it names two transports at once. TCP is the file-service conversation between the client and the NFS server. UDP is the encrypted carrier between the VPN endpoints. Neither one implies anything about the other.

Write both down separately before you debug anything; most of these incidents begin with someone changing the wrong layer.

Two layers, two settings

The mount option proto=tcp describes how the NFS client talks to the NFS server. The VPN profile's proto udp setting describes how the tunnel endpoints exchange encapsulated packets. Changing a mount option does not change the tunnel, and changing the tunnel transport does not change what the NFS client negotiated. Confirm the effective mount options with nfsstat -m rather than the fstab line, and confirm the VPN transport from the profile that is actually in use.

Then record them in the incident notes as two separate fields. An apparent improvement is only traceable if the note says which layer changed.

Browsing is not a bulk read

A directory listing proves that some operations completed. It does not establish that a sustained read, a write, a lock, or the storage backend will complete under the same conditions. A stall halfway through a large file is a different observation from a mount that never succeeds, and they point at different layers.

Describe the failing operation precisely: path, direction, approximate point of the stall, and the last relevant event in the client, server, and VPN logs. Then compare where traffic continues and where it stops.

MTU is a hypothesis, not a diagnosis

Packet-size-dependent loss is a real possibility when a tunnel carries large segments, and it produces exactly the browsing-works-reads-stall pattern. That pattern does not prove an MTU problem, though, because the same shape appears when a server is slow, a firewall times out a long-lived connection, or a disk is busy. Test the hypothesis with a controlled probe rather than lowering MTU everywhere and declaring victory.

A timeout on its own says nothing about whether UDP should be swapped out. It is a symptom with several possible owners.

Change one variable at a time

When comparing transports, keep the NFS workload and every other setting stable. Changing the mount transport, the tunnel protocol, and the MTU in the same maintenance window produces a result nobody can attribute. Run the same file operation before and after, and record the outcome at each step.

Keep the previous values in the ticket as well. If a change makes things worse, the fallback should be a documented number rather than someone's memory of what it used to be.

Read the layer that failed

If the tunnel is up and the NFS request is waiting, the VPN did not fail; the file service did. If the tunnel dropped, the NFS request failing is a consequence rather than a cause. Matching log lines from both layers is the fastest way to tell those two cases apart, and it beats guessing from the file manager.

Write the conclusion as two sentences, one per layer. That is enough for the next person to reproduce the test without re-deriving which transport is which.