Date: Wed, 18 Feb 2009 14:33:07 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Roman Kurakin <rik@inse.ru> Cc: n j <nino80@gmail.com>, freebsd-ipfw@freebsd.org Subject: Re: in-kernel nat and stateful inspection hangs system 7.1 RELEASE Message-ID: <20090218142336.U38905@sola.nimnet.asn.au> In-Reply-To: <499B4019.4060203@localhost.inse.ru> References: <1d3a1860902160108j372b4446pd21760984d253627@mail.gmail.com> <200902161428.n1GESLvL015103@lurza.secnetix.de> <1d3a1860902161412w2225734do71939efd32346a23@mail.gmail.com> <92bcbda50902170924h167125f2vf054ffd481ec1831@mail.gmail.com> <499B4019.4060203@localhost.inse.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Feb 2009, Roman Kurakin wrote: > n j wrote: > > > About 2 Minutes later after apply this rule set, system writes that bge1 > > > watchdog timeout --- resetting and then system hangs, keyboard doesnt > > > response. No logs can be observed. > > > > > > When i remove all skipto and checkstate rules, system work properly > > > without problems. I suspect about stateful inpection code. > > > > > > > Just to add a "me too" message to this thread, I also experienced > > system freezes (keyboard not working => hardware reset necessary) with > > in-kernel NAT and stateful rules. I had a repeatable case on a > > production server and hoped to replicate the bug on a different > > machine as the production server needed to go in, well, production; > > however thanks to complex setup of original machine (in-kernel NAT, > > vlans, openvpn...), lack of time and virtual environment, test > > scenario failed to produce a sensible bug report and I gave up until I > > saw OP reporting the same issue. > > > > Here is the rule that after a short while (probably the first packet > > to match the rule) freezes the machine: > > > > ipfw 00003 nat 123 log ip from x.x.x.0/24 to > > a.b.c.0/24,a.b.d.0/24,a.b.e.0/24 out # keep-state here causes freeze > > ... further down the chain... > > ipfw > > I know this is far from a good bug report, but stateful inspection > > code/in-kernel NAT mix might be worth looking into. > > > IIRC both natd and in-kernel nat do not support stateful rules. > > rik I'm not sure what sense '[nat|divert] .. keep-state' would make anyway. At least with divert, so I assume with nat, you can test for 'diverted' packets afterwards, so maybe the workaround would be to do keep-state on an allow or skipto for diverted packets (out) just after the nat? cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090218142336.U38905>