Date: Fri, 08 Jun 2012 17:36:31 +0200 From: Damien Fleuriot <ml@my.gd> To: freebsd-net@freebsd.org Subject: Re: PF "scrub reassemble tcp" makes a packet with invalid TCP checksum depending on the situation Message-ID: <4FD21BFF.4080803@my.gd> In-Reply-To: <4FD213DA.8050300@aliceblue.jp> References: <4FD213DA.8050300@aliceblue.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/8/12 5:01 PM, Kazuaki ODA wrote: > Hi all, > > Recently I received a e-mail from our customer that he could not browse > our web site. I thought that was strange at first because we and most > people could browse without problems, but he could not...umm, why? > > After some investigation I've found that our web server ignores SYN > packet he sent because that has invalid TCP checksum, and his original > packet has correct checksum but that is broken after passing our > firewall using PF packet filter on 7.4-RELASE. And further more, I've > noticed that such a invalid packet is made when original packet has TCP > timestamp option and the option does not start at 16-bit word boundary > like a packet that has TCP options <mss,wscale,sackOK,timestamp,eol>. > > After all, disabling "scrub reassemble tcp" rule resolved this problem. > But I have some questions: > > Is this a bug in PF code, or original packet violates RFC? As far as I > know, last TCP option must end at 32-bit boundary but there is no > restriction for each options about position, order etc. So I think this > is a bug. Correct? > > How many systems in the world that create such a SYN packet? I think > that many OSes add NOP options before timestamp option to adjust the > starting position, but the one our customer has does not. Unfortunately > I cannot get information from him about his network environment... > > -- > Kazuaki ODA Oh god, that font... Anyway, Reporting that we experience a problem that looks very much the same here on, at least, 8.1-RELEASE, 8.2-RELEASE. Unconfirmed on 8.3-RELEASE and 8-STABLE as we have not tested. We've also had to disabled tcp reassembly in scrubbing as it incorrectly caused packets to be dropped.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FD21BFF.4080803>