in-kernel nat and stateful inspection hangs system 7.1 RELEASE

[Ian Smith]

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