Ah hah! Found it. kern/9174: ipnat -f filename without ipf -E crashes
system. That was my problem..  so even though I was running ipf -f
filename before ipnat -f filename.nat the ipfilter rules weren't
enabled!

So--now this message is in the mailing list, and I'll tell folks my
NetBSD vitals:

NetBSD-1.4.2 release. port-i386. :)

marc

> I tried the /24 combinations in there as well..  I'm sitting at the
> console now, and it appears to be dying inside _nat_ioctl..  hrm..
> consistently with:
> 
> fault says:
> uvm_fault(0xc495e580, 0x0, 0, 1) -> 1
> kernel: page fault trap, code=0
> Stopped in ipnat at   _nat_ioctl+0x319:     cmpl   $0,0(%edx)
> 
> and..  edx is: 0x78  (show registers)
> 
> trace says:
> 
> _nat_ioctl(evilnumber,evilnumber,3,evilhexnumber) at _nat_ioctl+0x319
> _iplioctl(...)
> _spec_ioctl()
> _vn_ioctl()
> _sys_ioctl()
> _syscall()
> --- syscall (number 54) ---
> 
> Do I need to supply more information than this? I must be missing
> something here..  maybe NetBSD-current will solve my problem? I
> thought I compiled in all I needed..  ipfil(8) hooks (I know these
> aren't necessary, but I tried with and without just in case),
> ipfilter..  berkeley packet filter.. ..  just about everything
> actually.
> 
> Doh..  Help!
> 
> Sincerely,
> 
> Marc
> 
> > >ipnat -f -
> > >map ep0 10.0.0.0/255.255.255.0 -> 24.66.169.45/255.255.255.255
> > >result: kernel panic, reboot.
> > >
> > >also tried 0/32 for the 24.66.blah.. both cases same result.
> > >...
> > >I'm assuming I'm doing something wrong here..  would the fact that
> > >both the network cables are plugged into the same hub have something
> > >to do with this? I'm forced to monkeying with it remotely.. so if more
> > >details is required I'd be happy to follow instructions when I get
> > >home in three days.
> > 
> > i've not used ipnat yet, but i'd be guessing that it might be happier
> > with netmasks specified in terms of bits instead of masks as you have
> > them.  try /24 for the first one and /32 for the other...
> > 
> > just a guess.
>