NFS mount "hanging" when accessing from a server on a different subnet
Just wanted to update on this in case anyone runs in to the same problem.
Essentially it comes down to the state rules in Pf. By default Pf keeps state, and uses S/SA as a mask. However, it seems that the NFS server implementation on OS X attempts to start a conversation back to the client using a non-standard set of flags. This was causing it to fail because Pf simply dropped the packets. I gathered this by tcpdumping both the lan and farm interfaces. After tweaking the state flags for the rules between the subnets, the connection was established correctly.
However, it seems to Pf continued to filter out some packets due to some other form of internal normalization, and no amount of tweaking the options that I tried managed to get it work.
In the end, I ended up creating another interface on the file server and placing it directly on the farm vlan, bypassing the router altogether.
I haven't used pf
; but I think it was one of the first statefull filters. Maybe it's keeping account of the 'connections' and dropping them?
I'd look for any state-dependent filter rule. In Linux's iptables
usually the filter starts with a
ACCEPT all state RELATED,ESTABLISHED
because that way it won't have to recheck all the relevant rules for each packet after the first one. But since NFS is UDP based and doesn't care about long (even hours) periods of silence, maybe the router is losing the ESTABLISHED
state, and the new packets aren't valid for a start.
check if there's any 'keepalive' parameter to make the client send heartbeat packets after a minute or so of silence. if not, try NFS over TCP. (which does have heartbeat packets).
The first thing to do is ensure that the firewall is actually the culprit.
To do this, set your default block rules to log. On my firewalls, that's two lines at the top of the filter rules:
block in log
block out log
Wait for the NFS mount to hang again and check your log interface:
tcpdump -eeni pflog0 'host <client ip> and host <nfs server ip>'
If you're seeing these packets blocked at the firewall, please post your pf.conf. If not, we need to start looking beyond the firewall.