Date: Mon, 21 May 2012 11:27:50 +0200 From: Daniel Hartmeier <daniel@benzedrine.cx> To: Joerg Pulz <Joerg.Pulz@frm2.tum.de> Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-pf@freebsd.org Subject: Re: panic when using pf and route-to (maybe: bad fragment handling?) Message-ID: <20120521092750.GA20007@insomnia.benzedrine.cx> In-Reply-To: <201205210726.q4L7Q6m9064258@hades.admin.frm2>
index | next in thread | previous in thread | raw e-mail
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. Danielhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120521092750.GA20007>