Date: Thu, 11 Aug 2005 18:59:11 +0200 From: Max Laier <max@love2party.net> To: freebsd-pf@freebsd.org Subject: Re: Fwd: pf problems Message-ID: <200508111859.23803.max@love2party.net> In-Reply-To: <48239d3905081108355f37468c@mail.gmail.com> References: <48239d390508040958265ce62@mail.gmail.com> <48239d390508080452270c8d10@mail.gmail.com> <48239d3905081108355f37468c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2476019.Gkgfb7DMs5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 11 August 2005 17:35, Sergey Lapin wrote: > > **************************************************** > > ***************** Bug#3 (critical) ***************** > > **************************************************** > > > > Because route-to for "out" rules did not work well, we decided to add > > the redirection for "in" rules so we added > > > > pass in quick on $dmz_if route-to ($ext_if1 $ext_gw1) tagged > > DMZ_TO_EXT1 keep state > > pass in quick on $dmz_if route-to ($ext_if2 $ext_gw2) tagged > > DMZ_TO_EXT2 keep state > > > > right before before "pass out quick" rules. Everything started working > > right and it worked fine for some time but then firewall died (machine > > do not respond to keyboard and the only bring it back to live was to > > bounce power). After rebooting situation repeated - router was working > > well for 2 to 10 minutes and then unexpectedly freeze. We discovered > > that problem was caused by broadcast UDP packet coming on dmz_if and > > destined to 255.255.255.255 Later we discovered that this situation is > > triggered by any packet for which both conditions are true: > > 1. destination MAC is broadcast > > 2. destination IP is none of router's directly connected networks > > > > Any such a packet kills the router. Actually, router is not completely > > dead - it sends that damn packet over and over at huge speed to the > > outer interface. > > > > Even if I'm doing something completely wrong, router should NOT hang th= at > > way. > Okay, we tested FreeBSD 5.4, FreeBSD 6.0 and OpenBSD 3.7 Thanks for doing this research. Appreciated! > Bug #2 present everywhere. Which means it is pf bug (or misfeature) I'll leave that to the OpenBSD guys for the moment ... > Bug #3 is definitely FreeBSD specific - it does not hurt OpenBSD. =2E.. and focus on this one. You told in an earlier mail that you have bee= n=20 able to break to DDB while hung? Can you get a couple of traces from that= =20 machine so that we get an idea where we are spinning? Just break into the= =20 debugger, issue a "trace" followed by a "continue", break again, repeat. =20 =46innally you should make sure that you have a "interesting" trace (i.e.=20 something with pf_* functions) and "call doadump". On reboot secure the co= re=20 and get back to me. Thanks for your investigation and help! =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2476019.Gkgfb7DMs5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBC+4PrXyyEoT62BG0RAg6/AJ9f4c+s+lPjt2CsYPAcr3shXwCEngCfTG2f 08SeJxTSY+g/b7QDnWMxK1I= =TJ8C -----END PGP SIGNATURE----- --nextPart2476019.Gkgfb7DMs5--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508111859.23803.max>