[pf4freebsd] Re: nfsd send error 1 probably caused by pf ?

[Pyun YongHyeon]

On Thu, Nov 13, 2003 at 09:35:46PM +0100, Florian C. Smeets wrote:
 > 
 > if i remove this line (the last but one) the problem disapears:
 > 
 > pass out quick on $Int keep state
 > 
Hello,

I have spent serveral days to analyze the problem.
Here is detailed explanations from Daniel.

> A pf state entry will only correctly support window scaling if the state
> engine has seen both the initial SYN and SYN+ACK of the connection.
> 
> So, it's important that you create state on the initial SYN packet (the
> subsequent SYN+ACK will match the state) when you want windows scaling
> support.
> 
> Normally, rulesets create state on the first SYN only, as in
> 
>   block all
>   pass in  on $if proto tcp ... flags S/SA keep state
>   pass out on $if proto tcp ... flags S/SA keep state
> 
> This means only SYN (but not SYN+ACK) will match any TCP pass rules and
> create state. Any other TCP packets (SYN+ACK, etc.) will be blocked,
> unless they match an existing state entry.
> 
> This means window scaling (and other features that require that pf has
> seen the handshake for a state entry, like modulate state, etc.) will
> work. But if you flush the state entries, existing connections will
> break and have to be re-established by the peers (as only a new
> handshake can create state). So a pfctl -Fs (or firewall reboot) kills
> all ongoing TCP connections.
> 
> If you want pf to be able to pick up existing connections after a state
> table flush, you can remove 'flags S/SA' from the 'pass ... keep state'
> rules. This will create state when pf sees the next packet of an
> existing connection.
> 
> But state entries created from anything else but the initial SYN packet
> will not properly support some features (like wscale, sequence number
> modulation, etc.). If the existing connection has been using these, it
> will (or might) eventually break. In quite subtle ways, as we see now.
> 
> Your rules were not creating state (for incoming connections from the
> nfs client) on the initial SYN, but they passed the initial SYN
> statelessly and created state on the outgoing SYN+ACK. Hence, the state
> entries didn't see the full handshake, and wscale was not supported,
> leading to the breakage described.
> 
> This completely explains all the effects. I should have spotted it
> earlier.

In conclusion, you should create a state on a initial SYN packet in
order to avoid this NFS server error.
(e.g. pass in on $interface proto tcp all flags S/SA)

Thanks.

Regards,
Pyun YongHyeon
-- 
Pyun YongHyeon <http://www.kr.freebsd.org/~yongari>