From owner-freebsd-pf@FreeBSD.ORG Sat Dec 29 17:26:01 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06913E36 for ; Sat, 29 Dec 2012 17:26:01 +0000 (UTC) (envelope-from cyberleo@cyberleo.net) Received: from paka.cyberleo.net (mtumishi.cyberleo.net [216.226.128.201]) by mx1.freebsd.org (Postfix) with ESMTP id C771A8FC08 for ; Sat, 29 Dec 2012 17:26:00 +0000 (UTC) Received: from [172.16.44.4] (den.cyberleo.net [216.80.73.130]) by paka.cyberleo.net (Postfix) with ESMTPSA id E99BA3C924; Sat, 29 Dec 2012 12:25:58 -0500 (EST) Message-ID: <50DF27A6.40505@cyberleo.net> Date: Sat, 29 Dec 2012 11:25:58 -0600 From: CyberLeo Kitsana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121201 Thunderbird/10.0.11 MIME-Version: 1.0 To: Michael Grimm Subject: Re: [SOLVED]: nc: connect to b:b:b:b::1:1 port 53 (tcp) failed: Operation timed out References: <14C709A3-B608-44C3-B12F-5F6790AA60DC@odo.in-berlin.de> <50DEDA01.4060103@cyberleo.net> <5FA24BDE-D6EE-4C3F-B0DE-BC5CBE9EA7A8@odo.in-berlin.de> In-Reply-To: <5FA24BDE-D6EE-4C3F-B0DE-BC5CBE9EA7A8@odo.in-berlin.de> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-pf@freebsd.org" X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list 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: Sat, 29 Dec 2012 17:26:01 -0000 On 12/29/2012 08:31 AM, Michael Grimm wrote: > Hi -- > > On 29.12.2012, at 13:07, Kimmo Paasiala wrote: >> On Sat, Dec 29, 2012 at 1:54 PM, CyberLeo Kitsana wrote: >>> On 12/28/2012 05:59 AM, Michael Grimm wrote: > >>>> I do run both my primary and secondary nameservers (distinct servers) in FreeBSD jails1 and jail2 as outlined below: >>> >>>> I do see using tcpdump at server1: >>>> >>>> | 00:00:02.066251 xx:xx:xx:xx:xx > yy:yy:yy:yy:yy, ethertype IPv6 (0x86dd), length 94: (flowlabel 0xa3c71, hlim 63, next-header TCP (6) payload length: 40) b:b:b:b::1.64158 > a:a:a:a:1::1.53: Flags [S], >>>> cksum 0x959b (incorrect -> 0x58f9), seq 3833155181, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS val 495939599 ecr 0], length 0 >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> 9.1's PF appears to be either corrupting or not updating the packet >>> checksum when it touches IPv6 packets. I was not able to figure out how >>> or why in my brief perusal of the source, but it seems to affect more >>> than just NAT66. >>> >>> http://freebsd.1045724.n5.nabble.com/PF-IPv6-NAT-and-The-Curse-of-The-Invalid-Checksum-td5769669.html >> >> Afaik any kind of NAT on IPv6 is broken with pf(4) at the moment. >> > > > I've been told to change my outgoing rule from ... > > | pass out log on $extIF inet6 proto {tcp, udp, icmp6, gre} all modulate state > > ... to ... > > | pass out log on $extIF inet6 proto {tcp, udp, icmp6, gre} all > > ... and that did the trick! No more checksum and timeout errors. Now it works as expected. > > Just for me to learn: What change in code from 9.0 to 9.1 made that first rule break? I used that rule since 7.0, IIRC. > > And one last question: I do have "modulate state" for the corresponding IPv4 rule as well. Should I modify that as well? Sorry for that dumb question, but I don't know pf good enough to judge myself. 'modulate state' is a form of packet rewriting like NAT, though it rewrites sequence numbers and stuff instead of addresses and ports; it makes sense that this would be affected by whatever is breaking IPv6 checksum rewriting. It'll work fine for IPv4, though it may not provide any benefit if all the traffic is generated or consumed by the same TCP/IP stack (same machine and no VIMAGE). -- Fuzzy love, -CyberLeo Furry Peace! - http://www.fur.com/peace/