From owner-freebsd-pf@FreeBSD.ORG Mon May 21 14:20:08 2012 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 513901065672 for ; Mon, 21 May 2012 14:20:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DA7C98FC12 for ; Mon, 21 May 2012 14:20:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q4LEK4UE039522 for ; Mon, 21 May 2012 14:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4LEK4ds039516; Mon, 21 May 2012 14:20:04 GMT (envelope-from gnats) Date: Mon, 21 May 2012 14:20:04 GMT Message-Id: <201205211420.q4LEK4ds039516@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Joerg Pulz Cc: Subject: Re: kern/168190: [pf] 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 Reply-To: Joerg Pulz 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 14:20:08 -0000 The following reply was made to PR kern/168190; it has been noted by GNATS. From: Joerg Pulz To: Daniel Hartmeier Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) Date: Mon, 21 May 2012 16:14:30 +0200 (CEST) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 21 May 2012, Daniel Hartmeier wrote: > 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, thanks for looking at this and your explanation. The route-to rules are pretty specific: #### pf.conf ext_if="bge0" int_if="bge1" vpn_net="10.1.1.0/24" srv_net="172.16.1.0/24" gw_addr="172.16.1.254" scrub in all pass out on $ext_if route-to ($int_if $gw_addr) from $vpn_net to any keep state pass out on $int_if route-to ($int_if $gw_addr) from $vpn_net to $srv_net keep state #### pf.conf The default gateway for the host itself is reachable on the external interface and there is a static route for our internal networks (172.16.0.0/16) configured for the system itself. All client traffic has to hit the $gw_addr first regardless in which direction it goes afterwards, that's where the route-to rules kick in. Do they have to be even more specific if possible at all? Kind regards Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPuk3JSPOsGF+KA+MRAh9BAJ9TRkTeB12NtqYOOmdRcDaTpBjPOgCdE3S1 6rcDkcoro92HI/db4pMLDn4= =w64E -----END PGP SIGNATURE-----