PF "scrub reassemble tcp" makes a packet with invalid TCP checksum depending on the situation

[Damien Fleuriot]

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.