Date: Mon, 21 May 2012 14:20:04 GMT From: Joerg Pulz <Joerg.Pulz@frm2.tum.de> To: freebsd-pf@FreeBSD.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) Message-ID: <201205211420.q4LEK4ds039516@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/168190; it has been noted by GNATS. From: Joerg Pulz <Joerg.Pulz@frm2.tum.de> To: Daniel Hartmeier <daniel@benzedrine.cx> 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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201205211420.q4LEK4ds039516>