From owner-freebsd-pf@FreeBSD.ORG Wed Jan 15 21:50:01 2014 Return-Path: Delivered-To: freebsd-pf@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3A31D14 for ; Wed, 15 Jan 2014 21:50:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8FF3818E3 for ; Wed, 15 Jan 2014 21:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0FLo0OS080546 for ; Wed, 15 Jan 2014 21:50:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0FLo0Uq080545; Wed, 15 Jan 2014 21:50:00 GMT (envelope-from gnats) Date: Wed, 15 Jan 2014 21:50:00 GMT Message-Id: <201401152150.s0FLo0Uq080545@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org Cc: From: Martin Sugioarto Subject: Re: kern/179392: [pf] [ip6] Incorrect TCP checksums in rdr return packets X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Martin Sugioarto List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 21:50:01 -0000 The following reply was made to PR kern/179392; it has been noted by GNATS. From: Martin Sugioarto To: bug-followup@FreeBSD.org, paul@semiocast.com Cc: Subject: Re: kern/179392: [pf] [ip6] Incorrect TCP checksums in rdr return packets Date: Wed, 15 Jan 2014 22:36:53 +0100 Hello FreeBSD team, hello Paul, I would like to confirm this. The original PR says it all. I have also reproduced it on FreeBSD 9.2R. FreeBSD 9.2-RELEASE-p2 #3 r258725 on amd64 The checksum is not updated, tcpdump says it clearly. The packet is being quietly dropped and never arrives at the service listening socket. Here the comparison for two rules for an intercepting HTTP proxy: # works (IPv4) rdr on $if_int inet proto tcp \ from any to !$net_int port www -> 127.0.0.1 port 8118 # incorrect checksum (IPv6) rdr on $if_int inet6 proto tcp \ from any to !$net_int port www -> ::1 port 8118 In my opinion, this is quite important. It costed me a day to find out what is going on and I have come to the same conclusion as Paul (independently). Yours Martin Sugioarto