Date: Tue, 13 Nov 2007 22:12:51 +0530 From: Girish Venkatachalam <girishvenkatachalam@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: PF, bridge, states and window scaling problem Message-ID: <20071113164251.GA5640@saraswathy.susmita.org> In-Reply-To: <669132de0711130553q3fde2394yfdb9a63b5ed67f8d@mail.gmail.com> References: <669132de0711121208n32bfb827p4984c6d3383da713@mail.gmail.com> <20071113022053.GA17768@saraswathy.susmita.org> <669132de0711130553q3fde2394yfdb9a63b5ed67f8d@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15:53:38 Nov 13, Alupului Costin wrote: > When that client tries logging in to Yahoo Messenger I can see an > increase in the number of state-mismatch reported by pfctl -si. There > are states established, but after a while the packets simply do not > match the states created. Also they will not create new states and nor > will they match a catch-all rule which follows. > Have you tried bumping up the state expiry timeout values? > I have tried using "flags S/SA" with the filter rules. The result was > that states were created, but not matched by the rest of the packets > in the stream. Packets would just match a catch-all rule that follows > the above mentioned rules. Still it was better because the connection > wouldn't just stall, but after all that was not statefull inspection > anymore... States are established and looked up based on unique 5 tuples or whatever. I don't expect a bug here. I think the packets that do not match the existing state entries have different keys into the state lookup table. IOW they don't form part of the same stream. > I have tried the same setup (without the queues) on a router and I > used keep state on all the rules (even the inbound ones). Works > perfectly. So I guess the problem really is the bridge. In that case I > would kindly suggest that the pf.conf manual page should mention that > statefull firewall has an unpredictable behaviour on bridges. I.E. you > can not create states on inbound rules at all although filtering > works. Another problem is that states created by outbound traffic > don't seem to take into account the window scaling when the client > uses that. > I was a big fan of the bridge setup simply because it is transparent > and I would choose the bridge over the router setup anytime, provided > that it would work properly (i mean statefull firewall). > But bridging is more complicated to manage and this problem seems to point to that. Also did you read the other post? There is some info about bridging caused state mismatches. > I always flushed the old states over and over again. The flags did not > help me. As I mentioned earlier they did establish the connection on > the SYN packet, but the rest of the packets in the flow did not match > that connection. In that case I am pretty much exhausted. I can't think of any other possibility. > Have tried without normalization, without fragment reassembly, with > no-df... Pretty much all the combinations... > > I will answer here to Erik Osterholm also: > > Performance really is an issue here when I give up statefull > inspection. The firewall contains roughly 2000 filter rules and the > traffic passing through is 20kpps at peak hours. So it is a huge > difference between statefull and stateless filtering. If I drop the > stafefull filtering the machine simply cannot handle all the traffic, > or in the best case scenario it develops quite some latency. > Indeed. Stateful firewalling improves performance by a huge magnitude due to the shortcuts that packets take instead of having to descend down the pf ruleset. regards, Girish
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071113164251.GA5640>