From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 15:11:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD86C1065670 for ; Fri, 8 Jun 2012 15:11:00 +0000 (UTC) (envelope-from kazuaki@aliceblue.jp) Received: from p024afb.tokyff01.ap.so-net.ne.jp (p024afb.tokyff01.ap.so-net.ne.jp [121.2.74.251]) by mx1.freebsd.org (Postfix) with ESMTP id 9C56F8FC1F for ; Fri, 8 Jun 2012 15:11:00 +0000 (UTC) Received: from undine.local (unknown [192.168.11.46]) by p024afb.tokyff01.ap.so-net.ne.jp (Postfix) with ESMTP id D82121A4016 for ; Sat, 9 Jun 2012 00:01:46 +0900 (JST) Message-ID: <4FD213DA.8050300@aliceblue.jp> Date: Sat, 09 Jun 2012 00:01:46 +0900 From: Kazuaki ODA User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: PF "scrub reassemble tcp" makes a packet with invalid TCP checksum depending on the situation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 15:11:00 -0000 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 . 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