kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?)

[Joerg Pulz]

The following reply was made to PR kern/168190; it has been noted by GNATS.

From: Joerg Pulz <Joerg.Pulz at frm2.tum.de>
To: Daniel Hartmeier <daniel at benzedrine.cx>
Cc: FreeBSD-gnats-submit at freebsd.org, freebsd-pf at freebsd.org
Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad
 fragment handling?)
Date: Tue, 22 May 2012 08:05:39 +0200 (CEST)

 -----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-----