Skip site navigation (1)Skip section navigation (2)
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>