Skip site navigation (1)Skip section navigation (2)
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>
References:  <201205210726.q4L7Q6m9064258@hades.admin.frm2>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120521092750.GA20007>