panic when using pf and route-to (maybe: bad fragment handling?)

[Daniel Hartmeier]

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