Date: Thu, 16 Sep 2004 03:57:14 -0000 From: Pyun YongHyeon <yongari@kt-is.co.kr> To: pf4freebsd@freelists.org Subject: [pf4freebsd] Re: nfsd send error 1 probably caused by pf ? Message-ID: <20031120115632.GC20609@kt-is.co.kr> In-Reply-To: <3FB3EB22.8000802@kasimir.com> References: <3FB2ACA6.7030302@kasimir.com> <20031113032327.GA28113@kt-is.co.kr> <3FB3EB22.8000802@kasimir.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 13, 2003 at 09:35:46PM +0100, Florian C. Smeets wrote: >=20 > if i remove this line (the last but one) the problem disapears: >=20 > pass out quick on $Int keep state >=20 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 stat= e > engine has seen both the initial SYN and SYN+ACK of the connection. >=20 > 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. >=20 > Normally, rulesets create state on the first SYN only, as in >=20 > block all > pass in on $if proto tcp ... flags S/SA keep state > pass out on $if proto tcp ... flags S/SA keep state >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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 --=20 Pyun YongHyeon <http://www.kr.freebsd.org/~yongari>;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031120115632.GC20609>