Date: Tue, 22 May 2012 08:05:39 +0200 (CEST) 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?) Message-ID: <alpine.BSF.2.00.1205220801370.89783@unqrf.nqzva.sez2> In-Reply-To: <20120521165037.GA29536@insomnia.benzedrine.cx> References: <201205211420.q4LEK4ds039516@freefall.freebsd.org> <20120521165037.GA29536@insomnia.benzedrine.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 21 May 2012, Daniel Hartmeier wrote: > On Mon, May 21, 2012 at 02:20:04PM +0000, Joerg Pulz wrote: > >> 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 > > So something from $vpn_net comes in, gets routed to the default gateway > (on $ext_if side), attempts to pass out on $ext_if, matches the first > rule, route-to applies, packet gets re-routed to $gw_addr, passes out > on $int_if, matches the second rule, double route-to. > > All you need to do is prevent the second rule from applying for packets > where the first rule matched, like with tags: > > pass out on $ext_if route-to ($int_if $gw_addr) from $vpn_net to any keep state tag from_vpn > pass out on $int_if route-to ($int_if $gw_addr) from $vpn_net to $srv_net keep state > pass out on $int_if from $vpn_net to $srv_net keep state tagged from_vpn > > i.e. you add 'tag from_vpn' to the first rule, so packets matching it > get tagged, then you add a third rule without route-to that applies to > tagged packets, which wins last-match for such packets. > > Or, instead of adding a third rule, add '! tagged from_vpn' to the > second rule, if tagged packets can still pass out on $int_if by another > rule. And i got another panic, this time without pf(4) involved at all. Unfortunately "dump" in kdb is doing nothing but hang. :-( Here is what was displayed on the screen: panic: m_copym, offset > size of mbuf chain cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic_0x182 m_copym() at m_copym+0x280 ip_fragment() at ip_fragment+0x1e5 ip_output() at ip_output+0xeab ip_forward() at ip_forward+0x175 ip_input() at ip_input+0x5fd swi_net() at swi_net+0x15a intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xaf fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe - --- trap 0, rip = 0, rsp = 0xfffff8000241d00, rbp = 0 --- KDB: enter: panic [ thread pid 12 tid 100008 ] Any thoughts about this one? Kind regards Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPuyy2SPOsGF+KA+MRAtcgAJwO4zh4/AZN2tHhySI+24y+kozM3gCgn+HS /ZIUDnpvQCGdRWXYvvBauZw= =xctG -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1205220801370.89783>