From owner-freebsd-pf@FreeBSD.ORG Mon May 21 09:37:30 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7623A106564A; Mon, 21 May 2012 09:37:30 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id D19948FC17; Mon, 21 May 2012 09:37:29 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id q4L9RoCY030555 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 21 May 2012 11:27:50 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q4L9Roep024167; Mon, 21 May 2012 11:27:50 +0200 (MEST) Date: Mon, 21 May 2012 11:27:50 +0200 From: Daniel Hartmeier To: Joerg Pulz Message-ID: <20120521092750.GA20007@insomnia.benzedrine.cx> References: <201205210726.q4L7Q6m9064258@hades.admin.frm2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205210726.q4L7Q6m9064258@hades.admin.frm2> User-Agent: Mutt/1.5.12-2006-07-14 Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-pf@freebsd.org Subject: Re: panic when using pf and route-to (maybe: bad fragment handling?) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 21 May 2012 09:37:30 -0000 It looks like the byte order of ip_len is wrong, htons(334) = 19969, triggering fragmentation (334 < if_mtu, but 19969 > if_mtu). The reason is most likely the recursive pf_route() call: > m_copym() at m_copym+0x280 > ip_fragment() at ip_fragment+0x1e5 > pf_route() at pf_route+0x75c > pf_test() at pf_test+0xc29 > pf_route() at pf_route+0x30a > pf_test() at pf_test+0xc29 > pf_check_out() at pf_check_out+0x3a > pfil_run_hooks() at pfil_run_hooks+0xd2 > ip_output() at ip_output+0x655 i.e. the packet is filtered when going out on some interface, matching a route-to rule. Now the packet is filtered again on the routed-to interface. So far ok, this is expected. But now it matches a route-to rule again, possibly the same one, because it doesn't restrict the interface. Usually, this is not intentional (double route-to), and can be fixed by checking the route-to rule(s) and making them more restrictive. Semantics of such route-to chains are not well defined. There's an mbuf tag to prevent endless loops, but obviously even short chains are not working properly. I'd try to avoid them. Daniel