Date: Sat, 09 Jun 2012 00:01:46 +0900 From: Kazuaki ODA <kazuaki@aliceblue.jp> To: freebsd-net@freebsd.org Subject: PF "scrub reassemble tcp" makes a packet with invalid TCP checksum depending on the situation Message-ID: <4FD213DA.8050300@aliceblue.jp>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FD213DA.8050300>