It took more packets than usual (I had to run it full stream for about 10 seconds) but sure enough, it just rebooted with just the bimap rule. The other 2 were deleted completely.
One other thing, I changed the bimap to a rdr (as the main purpose of this is to be a webserver, and we allowed ICMP just for legacy reasons I guess). pix1# cat /etc/ipnat.rules rdr fxp0 1.2.3.231/32 port 80 -> 10.10.2.231 port 80 And it clearly doesn't die now as the icmp packets are lost in oblivion (well the box stops responding during the load, but upon stopping it comes right back to life). The best part is if I send it packets for 1 minute, as I said the box stops responding, but not only that, time freezes on the box. When it wakes back up, the time is now 1 minute slow. But it indeed does not die. So it's ONLY when the bimap rule is there (and I guess it's bimap'ing the packets) that it dies. Greg * Darren Reed ([EMAIL PROTECTED]) [030530 19:27]: > In some email I received from Greg Rumple, sie wrote: > > And sure enough, I found a DoS tool that will crash it (with the error I > > was getting) like clockwork. I can cause it to crash in as little as 10 > > packets (it's an ICMP exploit btw interestingly enough (and rebuilding > > the kernel with no INET6 didn't help btw)). > > > > I also started taking pieces out of the kernel in an attempt to narrow > > it down. What I found was it only happens when I use the BIMAP piece of > > the puzzle (along with the proxy arp of course). I basically stripped > > my system down to the following. > > > > No ipf rules (so allow everything) > > > > ipnat.rules > > ----------- > > bimap fxp0 10.10.2.231/32 -> 1.2.3.231/32 > > If you remove the next two rules, it still panic's ? > > > map fxp0 10.10.2.0/24 -> 1.2.3.70/32 portmap tcp/udp 1025:65000 > > map fxp0 10.10.2.0/24 -> 1.2.3.70/32 > > Darren > -- Greg Rumple [EMAIL PROTECTED]
